Iptables not forwarding. Input instead












1















I have set up iptables on my ubuntu headless server:



iptables -S

-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -s 10.1.3.90/32 -i eth0 -j LOG --log-prefix "INPUT: "
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i ppp0 -j ACCEPT
-A FORWARD -s 10.1.3.90/32 -i eth0 -j LOG --log-prefix "FORWARD: "
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i ppp0 -o eth0 -j ACCEPT

iptables -S -t nat

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -s 10.1.3.90/32 -j LOG --log-prefix "ROUTE: "
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A PREROUTING -i eth0 -p tcp -m tcp --dport 11108 -j DNAT --to-destination 169.254.1.2:11108
-A PREROUTING -i eth0 -p udp -m udp --dport 11108 -j DNAT --to-destination 169.254.1.2:11108
-A PREROUTING -i eth0 -p tcp -m tcp --dport 5555 -j DNAT --to-destination 169.254.1.2:5555
-A PREROUTING -i eth0 -j DNAT --to-destination 169.254.2.2
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -s 169.254.1.2/32 -o eth0 -j MASQUERADE
-A POSTROUTING -s 169.254.2.2/32 -o eth0 -j MASQUERADE


When i send UDP packet to port 11108 it should be routed to ppp0 169.254.1.2:11108 and FORWARD rule should apply.
instead a INPUT rule is applied and packet is not routed.



this is the log from kernel. there is no FORWARD:



Jun 20 10:58:51 ubuntu kernel: [  337.871043] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=22127 PROTO=UDP SPT=11108 DPT=11108 LEN=32 
Jun 20 10:58:53 ubuntu kernel: [ 339.865420] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=22484 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:58:55 ubuntu kernel: [ 341.864446] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=22818 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:58:57 ubuntu kernel: [ 343.707469] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=23133 PROTO=UDP SPT=138 DPT=138 LEN=209
Jun 20 10:58:57 ubuntu kernel: [ 343.863994] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=23266 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:58:59 ubuntu kernel: [ 345.877465] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=23684 PROTO=UDP SPT=11108 DPT=11108 LEN=32
Jun 20 10:58:59 ubuntu kernel: [ 345.879215] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=23707 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:59:00 ubuntu kernel: [ 346.010347] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=23798 PROTO=UDP SPT=137 DPT=137 LEN=58
Jun 20 10:59:00 ubuntu kernel: [ 346.759893] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=23811 PROTO=UDP SPT=137 DPT=137 LEN=58
Jun 20 10:59:01 ubuntu kernel: [ 347.509887] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=23944 PROTO=UDP SPT=137 DPT=137 LEN=58
Jun 20 10:59:01 ubuntu kernel: [ 347.878185] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=24086 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:59:01 ubuntu kernel: [ 347.881900] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=24109 PROTO=UDP SPT=11108 DPT=11108 LEN=32









share|improve this question


















  • 1





    Is the 169.254.1.2 address assigned to an interface on the same machine? IIRC, the packet won't hit the FORWARD chain in that case since it's handled/routed internally, assuming you've enabled IP forwarding.

    – Mark
    Jun 20 '14 at 10:42











  • no the 169.254.1.2 is on the other side of P2P connection ppp0. it is android connected via adb. The link is ok. i can ping it from ubuntu and back

    – Mazmart
    Jun 20 '14 at 10:50











  • Your FORWARD chain is set to drop as the default, but you aren't allowing forwarding from eth0 to ppp0 (-i eth0 -o ppp0) in your rules. Can you also confirm that IP forwarding is enabled in /proc/sys/net/ipv4/conf/all/forwarding?

    – Mark
    Jun 20 '14 at 11:02











  • i've tried the FORWARD -i eth0 -o ppp0 but it did not help. It shoulb be covered in general -i eth0 rule. And yes ip_forward is enabled in sysctl

    – Mazmart
    Jun 20 '14 at 11:10













  • I've found out that the port i'm trying to redirect is open at the time of redirection. there could be ongoing communication on this port but i need to redirect it anyway.

    – Mazmart
    Jun 20 '14 at 11:12
















1















I have set up iptables on my ubuntu headless server:



iptables -S

-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -s 10.1.3.90/32 -i eth0 -j LOG --log-prefix "INPUT: "
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i ppp0 -j ACCEPT
-A FORWARD -s 10.1.3.90/32 -i eth0 -j LOG --log-prefix "FORWARD: "
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i ppp0 -o eth0 -j ACCEPT

iptables -S -t nat

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -s 10.1.3.90/32 -j LOG --log-prefix "ROUTE: "
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A PREROUTING -i eth0 -p tcp -m tcp --dport 11108 -j DNAT --to-destination 169.254.1.2:11108
-A PREROUTING -i eth0 -p udp -m udp --dport 11108 -j DNAT --to-destination 169.254.1.2:11108
-A PREROUTING -i eth0 -p tcp -m tcp --dport 5555 -j DNAT --to-destination 169.254.1.2:5555
-A PREROUTING -i eth0 -j DNAT --to-destination 169.254.2.2
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -s 169.254.1.2/32 -o eth0 -j MASQUERADE
-A POSTROUTING -s 169.254.2.2/32 -o eth0 -j MASQUERADE


When i send UDP packet to port 11108 it should be routed to ppp0 169.254.1.2:11108 and FORWARD rule should apply.
instead a INPUT rule is applied and packet is not routed.



this is the log from kernel. there is no FORWARD:



Jun 20 10:58:51 ubuntu kernel: [  337.871043] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=22127 PROTO=UDP SPT=11108 DPT=11108 LEN=32 
Jun 20 10:58:53 ubuntu kernel: [ 339.865420] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=22484 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:58:55 ubuntu kernel: [ 341.864446] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=22818 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:58:57 ubuntu kernel: [ 343.707469] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=23133 PROTO=UDP SPT=138 DPT=138 LEN=209
Jun 20 10:58:57 ubuntu kernel: [ 343.863994] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=23266 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:58:59 ubuntu kernel: [ 345.877465] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=23684 PROTO=UDP SPT=11108 DPT=11108 LEN=32
Jun 20 10:58:59 ubuntu kernel: [ 345.879215] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=23707 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:59:00 ubuntu kernel: [ 346.010347] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=23798 PROTO=UDP SPT=137 DPT=137 LEN=58
Jun 20 10:59:00 ubuntu kernel: [ 346.759893] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=23811 PROTO=UDP SPT=137 DPT=137 LEN=58
Jun 20 10:59:01 ubuntu kernel: [ 347.509887] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=23944 PROTO=UDP SPT=137 DPT=137 LEN=58
Jun 20 10:59:01 ubuntu kernel: [ 347.878185] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=24086 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:59:01 ubuntu kernel: [ 347.881900] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=24109 PROTO=UDP SPT=11108 DPT=11108 LEN=32









share|improve this question


















  • 1





    Is the 169.254.1.2 address assigned to an interface on the same machine? IIRC, the packet won't hit the FORWARD chain in that case since it's handled/routed internally, assuming you've enabled IP forwarding.

    – Mark
    Jun 20 '14 at 10:42











  • no the 169.254.1.2 is on the other side of P2P connection ppp0. it is android connected via adb. The link is ok. i can ping it from ubuntu and back

    – Mazmart
    Jun 20 '14 at 10:50











  • Your FORWARD chain is set to drop as the default, but you aren't allowing forwarding from eth0 to ppp0 (-i eth0 -o ppp0) in your rules. Can you also confirm that IP forwarding is enabled in /proc/sys/net/ipv4/conf/all/forwarding?

    – Mark
    Jun 20 '14 at 11:02











  • i've tried the FORWARD -i eth0 -o ppp0 but it did not help. It shoulb be covered in general -i eth0 rule. And yes ip_forward is enabled in sysctl

    – Mazmart
    Jun 20 '14 at 11:10













  • I've found out that the port i'm trying to redirect is open at the time of redirection. there could be ongoing communication on this port but i need to redirect it anyway.

    – Mazmart
    Jun 20 '14 at 11:12














1












1








1


1






I have set up iptables on my ubuntu headless server:



iptables -S

-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -s 10.1.3.90/32 -i eth0 -j LOG --log-prefix "INPUT: "
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i ppp0 -j ACCEPT
-A FORWARD -s 10.1.3.90/32 -i eth0 -j LOG --log-prefix "FORWARD: "
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i ppp0 -o eth0 -j ACCEPT

iptables -S -t nat

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -s 10.1.3.90/32 -j LOG --log-prefix "ROUTE: "
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A PREROUTING -i eth0 -p tcp -m tcp --dport 11108 -j DNAT --to-destination 169.254.1.2:11108
-A PREROUTING -i eth0 -p udp -m udp --dport 11108 -j DNAT --to-destination 169.254.1.2:11108
-A PREROUTING -i eth0 -p tcp -m tcp --dport 5555 -j DNAT --to-destination 169.254.1.2:5555
-A PREROUTING -i eth0 -j DNAT --to-destination 169.254.2.2
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -s 169.254.1.2/32 -o eth0 -j MASQUERADE
-A POSTROUTING -s 169.254.2.2/32 -o eth0 -j MASQUERADE


When i send UDP packet to port 11108 it should be routed to ppp0 169.254.1.2:11108 and FORWARD rule should apply.
instead a INPUT rule is applied and packet is not routed.



this is the log from kernel. there is no FORWARD:



Jun 20 10:58:51 ubuntu kernel: [  337.871043] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=22127 PROTO=UDP SPT=11108 DPT=11108 LEN=32 
Jun 20 10:58:53 ubuntu kernel: [ 339.865420] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=22484 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:58:55 ubuntu kernel: [ 341.864446] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=22818 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:58:57 ubuntu kernel: [ 343.707469] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=23133 PROTO=UDP SPT=138 DPT=138 LEN=209
Jun 20 10:58:57 ubuntu kernel: [ 343.863994] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=23266 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:58:59 ubuntu kernel: [ 345.877465] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=23684 PROTO=UDP SPT=11108 DPT=11108 LEN=32
Jun 20 10:58:59 ubuntu kernel: [ 345.879215] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=23707 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:59:00 ubuntu kernel: [ 346.010347] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=23798 PROTO=UDP SPT=137 DPT=137 LEN=58
Jun 20 10:59:00 ubuntu kernel: [ 346.759893] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=23811 PROTO=UDP SPT=137 DPT=137 LEN=58
Jun 20 10:59:01 ubuntu kernel: [ 347.509887] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=23944 PROTO=UDP SPT=137 DPT=137 LEN=58
Jun 20 10:59:01 ubuntu kernel: [ 347.878185] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=24086 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:59:01 ubuntu kernel: [ 347.881900] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=24109 PROTO=UDP SPT=11108 DPT=11108 LEN=32









share|improve this question














I have set up iptables on my ubuntu headless server:



iptables -S

-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -s 10.1.3.90/32 -i eth0 -j LOG --log-prefix "INPUT: "
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i ppp0 -j ACCEPT
-A FORWARD -s 10.1.3.90/32 -i eth0 -j LOG --log-prefix "FORWARD: "
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i ppp0 -o eth0 -j ACCEPT

iptables -S -t nat

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -s 10.1.3.90/32 -j LOG --log-prefix "ROUTE: "
-A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A PREROUTING -i eth0 -p tcp -m tcp --dport 11108 -j DNAT --to-destination 169.254.1.2:11108
-A PREROUTING -i eth0 -p udp -m udp --dport 11108 -j DNAT --to-destination 169.254.1.2:11108
-A PREROUTING -i eth0 -p tcp -m tcp --dport 5555 -j DNAT --to-destination 169.254.1.2:5555
-A PREROUTING -i eth0 -j DNAT --to-destination 169.254.2.2
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -s 169.254.1.2/32 -o eth0 -j MASQUERADE
-A POSTROUTING -s 169.254.2.2/32 -o eth0 -j MASQUERADE


When i send UDP packet to port 11108 it should be routed to ppp0 169.254.1.2:11108 and FORWARD rule should apply.
instead a INPUT rule is applied and packet is not routed.



this is the log from kernel. there is no FORWARD:



Jun 20 10:58:51 ubuntu kernel: [  337.871043] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=22127 PROTO=UDP SPT=11108 DPT=11108 LEN=32 
Jun 20 10:58:53 ubuntu kernel: [ 339.865420] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=22484 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:58:55 ubuntu kernel: [ 341.864446] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=22818 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:58:57 ubuntu kernel: [ 343.707469] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=23133 PROTO=UDP SPT=138 DPT=138 LEN=209
Jun 20 10:58:57 ubuntu kernel: [ 343.863994] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=23266 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:58:59 ubuntu kernel: [ 345.877465] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=23684 PROTO=UDP SPT=11108 DPT=11108 LEN=32
Jun 20 10:58:59 ubuntu kernel: [ 345.879215] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=23707 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:59:00 ubuntu kernel: [ 346.010347] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=23798 PROTO=UDP SPT=137 DPT=137 LEN=58
Jun 20 10:59:00 ubuntu kernel: [ 346.759893] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=23811 PROTO=UDP SPT=137 DPT=137 LEN=58
Jun 20 10:59:01 ubuntu kernel: [ 347.509887] ROUTE: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=23944 PROTO=UDP SPT=137 DPT=137 LEN=58
Jun 20 10:59:01 ubuntu kernel: [ 347.878185] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=24086 PROTO=UDP SPT=11108 DPT=11108 LEN=48
Jun 20 10:59:01 ubuntu kernel: [ 347.881900] INPUT: IN=eth0 OUT= MAC=00:1c:42:02:04:dd:00:1c:42:d7:b0:24:08:00 SRC=10.1.3.90 DST=10.1.3.117 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=24109 PROTO=UDP SPT=11108 DPT=11108 LEN=32






ubuntu iptables routing






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jun 20 '14 at 9:24









MazmartMazmart

1214




1214








  • 1





    Is the 169.254.1.2 address assigned to an interface on the same machine? IIRC, the packet won't hit the FORWARD chain in that case since it's handled/routed internally, assuming you've enabled IP forwarding.

    – Mark
    Jun 20 '14 at 10:42











  • no the 169.254.1.2 is on the other side of P2P connection ppp0. it is android connected via adb. The link is ok. i can ping it from ubuntu and back

    – Mazmart
    Jun 20 '14 at 10:50











  • Your FORWARD chain is set to drop as the default, but you aren't allowing forwarding from eth0 to ppp0 (-i eth0 -o ppp0) in your rules. Can you also confirm that IP forwarding is enabled in /proc/sys/net/ipv4/conf/all/forwarding?

    – Mark
    Jun 20 '14 at 11:02











  • i've tried the FORWARD -i eth0 -o ppp0 but it did not help. It shoulb be covered in general -i eth0 rule. And yes ip_forward is enabled in sysctl

    – Mazmart
    Jun 20 '14 at 11:10













  • I've found out that the port i'm trying to redirect is open at the time of redirection. there could be ongoing communication on this port but i need to redirect it anyway.

    – Mazmart
    Jun 20 '14 at 11:12














  • 1





    Is the 169.254.1.2 address assigned to an interface on the same machine? IIRC, the packet won't hit the FORWARD chain in that case since it's handled/routed internally, assuming you've enabled IP forwarding.

    – Mark
    Jun 20 '14 at 10:42











  • no the 169.254.1.2 is on the other side of P2P connection ppp0. it is android connected via adb. The link is ok. i can ping it from ubuntu and back

    – Mazmart
    Jun 20 '14 at 10:50











  • Your FORWARD chain is set to drop as the default, but you aren't allowing forwarding from eth0 to ppp0 (-i eth0 -o ppp0) in your rules. Can you also confirm that IP forwarding is enabled in /proc/sys/net/ipv4/conf/all/forwarding?

    – Mark
    Jun 20 '14 at 11:02











  • i've tried the FORWARD -i eth0 -o ppp0 but it did not help. It shoulb be covered in general -i eth0 rule. And yes ip_forward is enabled in sysctl

    – Mazmart
    Jun 20 '14 at 11:10













  • I've found out that the port i'm trying to redirect is open at the time of redirection. there could be ongoing communication on this port but i need to redirect it anyway.

    – Mazmart
    Jun 20 '14 at 11:12








1




1





Is the 169.254.1.2 address assigned to an interface on the same machine? IIRC, the packet won't hit the FORWARD chain in that case since it's handled/routed internally, assuming you've enabled IP forwarding.

– Mark
Jun 20 '14 at 10:42





Is the 169.254.1.2 address assigned to an interface on the same machine? IIRC, the packet won't hit the FORWARD chain in that case since it's handled/routed internally, assuming you've enabled IP forwarding.

– Mark
Jun 20 '14 at 10:42













no the 169.254.1.2 is on the other side of P2P connection ppp0. it is android connected via adb. The link is ok. i can ping it from ubuntu and back

– Mazmart
Jun 20 '14 at 10:50





no the 169.254.1.2 is on the other side of P2P connection ppp0. it is android connected via adb. The link is ok. i can ping it from ubuntu and back

– Mazmart
Jun 20 '14 at 10:50













Your FORWARD chain is set to drop as the default, but you aren't allowing forwarding from eth0 to ppp0 (-i eth0 -o ppp0) in your rules. Can you also confirm that IP forwarding is enabled in /proc/sys/net/ipv4/conf/all/forwarding?

– Mark
Jun 20 '14 at 11:02





Your FORWARD chain is set to drop as the default, but you aren't allowing forwarding from eth0 to ppp0 (-i eth0 -o ppp0) in your rules. Can you also confirm that IP forwarding is enabled in /proc/sys/net/ipv4/conf/all/forwarding?

– Mark
Jun 20 '14 at 11:02













i've tried the FORWARD -i eth0 -o ppp0 but it did not help. It shoulb be covered in general -i eth0 rule. And yes ip_forward is enabled in sysctl

– Mazmart
Jun 20 '14 at 11:10







i've tried the FORWARD -i eth0 -o ppp0 but it did not help. It shoulb be covered in general -i eth0 rule. And yes ip_forward is enabled in sysctl

– Mazmart
Jun 20 '14 at 11:10















I've found out that the port i'm trying to redirect is open at the time of redirection. there could be ongoing communication on this port but i need to redirect it anyway.

– Mazmart
Jun 20 '14 at 11:12





I've found out that the port i'm trying to redirect is open at the time of redirection. there could be ongoing communication on this port but i need to redirect it anyway.

– Mazmart
Jun 20 '14 at 11:12










1 Answer
1






active

oldest

votes


















0














Reduce your ruleset to the bare minimum and start testing from there. There's some redundant rules which may be conflicting. I would start with:



-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i eth0 -p udp -m udp --dport 11108 -j DNAT --to-destination 169.254.1.2:11108


I would also use watch to see what chains/rules the packets are hitting



watch -n1 iptables -vnL
watch -n1 iptables -vnl -t nat


The APIPA address isn't necessarily the best thing to use for the client, but that shouldn't affect receiving packets.






share|improve this answer


























  • Sorry didn't help. I've traced the error to that if i use the port on local machine before redirection is applied then the rule is not forwarded. If i don't use the port before it works correctly

    – Mazmart
    Jun 24 '14 at 12:24












Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f138227%2fiptables-not-forwarding-input-instead%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














Reduce your ruleset to the bare minimum and start testing from there. There's some redundant rules which may be conflicting. I would start with:



-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i eth0 -p udp -m udp --dport 11108 -j DNAT --to-destination 169.254.1.2:11108


I would also use watch to see what chains/rules the packets are hitting



watch -n1 iptables -vnL
watch -n1 iptables -vnl -t nat


The APIPA address isn't necessarily the best thing to use for the client, but that shouldn't affect receiving packets.






share|improve this answer


























  • Sorry didn't help. I've traced the error to that if i use the port on local machine before redirection is applied then the rule is not forwarded. If i don't use the port before it works correctly

    – Mazmart
    Jun 24 '14 at 12:24
















0














Reduce your ruleset to the bare minimum and start testing from there. There's some redundant rules which may be conflicting. I would start with:



-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i eth0 -p udp -m udp --dport 11108 -j DNAT --to-destination 169.254.1.2:11108


I would also use watch to see what chains/rules the packets are hitting



watch -n1 iptables -vnL
watch -n1 iptables -vnl -t nat


The APIPA address isn't necessarily the best thing to use for the client, but that shouldn't affect receiving packets.






share|improve this answer


























  • Sorry didn't help. I've traced the error to that if i use the port on local machine before redirection is applied then the rule is not forwarded. If i don't use the port before it works correctly

    – Mazmart
    Jun 24 '14 at 12:24














0












0








0







Reduce your ruleset to the bare minimum and start testing from there. There's some redundant rules which may be conflicting. I would start with:



-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i eth0 -p udp -m udp --dport 11108 -j DNAT --to-destination 169.254.1.2:11108


I would also use watch to see what chains/rules the packets are hitting



watch -n1 iptables -vnL
watch -n1 iptables -vnl -t nat


The APIPA address isn't necessarily the best thing to use for the client, but that shouldn't affect receiving packets.






share|improve this answer















Reduce your ruleset to the bare minimum and start testing from there. There's some redundant rules which may be conflicting. I would start with:



-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i eth0 -p udp -m udp --dport 11108 -j DNAT --to-destination 169.254.1.2:11108


I would also use watch to see what chains/rules the packets are hitting



watch -n1 iptables -vnL
watch -n1 iptables -vnl -t nat


The APIPA address isn't necessarily the best thing to use for the client, but that shouldn't affect receiving packets.







share|improve this answer














share|improve this answer



share|improve this answer








edited Jun 20 '14 at 16:26

























answered Jun 20 '14 at 14:13









CreekCreek

3,76611229




3,76611229













  • Sorry didn't help. I've traced the error to that if i use the port on local machine before redirection is applied then the rule is not forwarded. If i don't use the port before it works correctly

    – Mazmart
    Jun 24 '14 at 12:24



















  • Sorry didn't help. I've traced the error to that if i use the port on local machine before redirection is applied then the rule is not forwarded. If i don't use the port before it works correctly

    – Mazmart
    Jun 24 '14 at 12:24

















Sorry didn't help. I've traced the error to that if i use the port on local machine before redirection is applied then the rule is not forwarded. If i don't use the port before it works correctly

– Mazmart
Jun 24 '14 at 12:24





Sorry didn't help. I've traced the error to that if i use the port on local machine before redirection is applied then the rule is not forwarded. If i don't use the port before it works correctly

– Mazmart
Jun 24 '14 at 12:24


















draft saved

draft discarded




















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f138227%2fiptables-not-forwarding-input-instead%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

How to make a Squid Proxy server?

第一次世界大戦

Touch on Surface Book