Iptables not forwarding. Input instead
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
add a comment |
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
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
add a comment |
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
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
ubuntu iptables routing
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
add a comment |
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
add a comment |
1 Answer
1
active
oldest
votes
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.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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