Failing to do IP Forwarding [SOLVED]

[gregbert]

Hi, I have an archlinux that was, at one point doing NAT across a ppp0 connection. this archlinuxarm pogoplug e02 is a client of a pptp vpn. This is a pretty dense set of information i am providing below. thank you very much for attempting to help me sort it out.

Key information:
Archlinuxarm machine that i desire to do IP forwarding: 192.168.1.6
Destination network, over ppp0: 192.167.0.0/24
Router @ 192.168.1.1 has static route for 192.167.0.0/24 traffic to be sent to 192.167.1.6 - take this as a given. I know it works, as i can follow packets and see they are being forwarded to 192.168.1.6.

Results:
From 192.168.1.6 - i can ping the entire 192.167.0.0 network, no problem
From any other 192.168.1.x machine, i can ping 192.167.1.6, but nothing on the 192.167.0.0/24 ntework.
Interestingly, i also cannot ping the local ppp0 address of the 192.167.1.6 machine (192.167.0.200) or the router on the other side of the VPN connection (192.167.0.99) - this is definitely the canary in the coal mine.

I use this script to set IP forwarding. It worked when i first set it up. But after installing other programs (e.g. nfs-utils, plexmediaserver, etc etc) it stopped working.

$this->bbcode_second_pass_code('', 'iptables --flush # Flush all the rules in filter and nat tables
iptables --table nat --flush
iptables --delete-chain # Delete all chains that are not in default filter and nat table
iptables --table nat --delete-chain

# Set up IP FORWARDing and Masquerading
iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE
iptables --append FORWARD --in-interface eth0 -j ACCEPT # Assuming one NIC to local LAN

echo 1 > /proc/sys/net/ipv4/ip_forward # Enables packet forwarding by kernel
')


here is the ippr adr

$this->bbcode_second_pass_code('', '1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether MAC:MASKED brd ff:ff:ff:ff:ff:ff
inet 192.168.1.6/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 45419sec preferred_lft 45419sec
inet6 mac:masked/64 scope link
valid_lft forever preferred_lft forever
10: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1432 qdisc pfifo_fast state UNKNOWN group default qlen 3
link/ppp
inet 192.167.0.200 peer 192.167.0.99/32 scope global ppp0
valid_lft forever preferred_lft forever
')

Here is the iptables -L

$this->bbcode_second_pass_code('', 'Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
')

and here is the iptables -t nat -L

$this->bbcode_second_pass_code('', 'Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- anywhere anywhere
')

Please let me know what other information i can provide... i find ip forwarding and routing to be one of the most confusing topics to try to address.. thank you very much

[WarheadsSE]

You may need to individually set up the ip forwarding per device (newer kernels, and systemd have made it isolatable per network device)

[gregbert]

Bingo

find a file called /proc/sys/net/ipv4/conf/eth0/forwarding
had a 0 in it
made it a 1
all of a sudden, everything works again

thank you

[gregbert]

As i said in previous post, I am now able to ping 192.167.0.0/24 network from the 192.168.1.0/24 network by routing traffic through 192.167.0.200 - the archlinux box.

I could not do the reverse (e.g. ping the 192.168.1.0/24 network from a 192.167.0.x machine)

i though all i would need to do is add the reciprocal iptables entries, but it doesnt work. here's my current iptables script. Is there something else i need to do to allow masquarading in the ppp0 --> eth0 direction? thanks again for helping me to quickly solve the main issue in the other direction.

$this->bbcode_second_pass_code('', 'iptables --flush # Flush all the rules in filter and nat tables
iptables --table nat --flush
iptables --delete-chain # Delete all chains that are not in default filter and nat table
iptables --table nat --delete-chain

# Set up IP FORWARDing and Masquerading
iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE
iptables --append FORWARD --in-interface eth0 -j ACCEPT # Assuming one NIC to local LAN

# NEW LINES HERE
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface ppp0 -j ACCEPT # Assuming one NIC to local LAN

echo 1 > /proc/sys/net/ipv4/ip_forward # Enables packet forwarding by kernel
echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding
echo 1 > /proc/sys/net/ipv4/conf/ppp0/forwarding
')

[WarheadsSE]

$this->bbcode_second_pass_code('', 'iptables -t nat -A POSTROUTING -s 10.0.0.1/32 -o eth0 -j MASQUERADE')

That is all that was needed for use with the USB Armory. (see the installation instructions)

[gregbert]

Hi Warhead

Thanks for the reply. I've gone through the installation instructions and tried to understand what the usb armory is.

In the USB armory case, i understand it has an IP of 10.0.0.1 and can reach the larger network (which is, lets say, 192.168.1.0/24). I can do that too at this point. (e.g. ping my 192.167.0.0/24 network from any of my 192.168.1.0/24 computers on the other side of the ppp0 connection)

But, in your USB Armory example, can one of the computers on the larger network (e.g. 192.168.1.0/24) ping or ssh to 10.0.0.1? to do that, what would you need to add? not with that single iptables entry below obviously since its restricted to packets sourced from 10.0.0.1/32.

i made a quick sketch in in case it helps. i assume masquarading is still the right thing to do here, but let me know if that is what is screwing things up...

thank you

[WarheadsSE]

Well, according to the layout it should work, but you might have some issues with the routing tables if it is not occurring properly.

[gregbert]

Warhead,

Sorting through some other things now - but wanted to let you know that this was right. After seeing your post, i went and investigated the routes on each machine. I found on on the 192.167.0.99 router that the route for 192.168.1.0/24 was indeed forwarded to 192.167.0.200 as desired - however, the device was incorrectly specified as br0 rather than ppp0. fixing that, all of a sudden, i have connectivity. i was even able to get rid of the masquerading in both directions.

thank you for the continued tips. i am sure i will have more questions.