FRC, Routing, VPNs, and Subnets

[linuxboy]

Hi all,
I have a very interesting networking issue that you all may be interested in taking a crack at. I have 3 subnets at my house (which is where the robot currently resides). The first is 192.168.1.0/24 it is the network on which all the normal devices in my house operate (everyone's computers and mobile devices). I then have a virtual subnet 192.168.10.0/24 on which VPN clients get assigned IP addresses. Lastly I have the robot subnet 10.37.80.0/24 on which all the robot stuff connects (this is done to keep the robot network clear of extraneous broadcasts from all the other devices). Pinging any device on any subnet works fine from the other subnet (ICMP requests are all routed properly), as well as TCP as far as I can tell. The issue occurs when trying to receive UDP packets on the VPN subnet from the robot. Using tcpdump I figured out that the UDP packets from the DS are successfully routed to the physical network, and the responses are successfully routed to the VPN gateway, however, they do not reach the virtual network that is 192.168.10.0/24
The VPN gateway is running linux and routing is done with iptables.
The INPUT and FORWARD chains both have a policy of accept and the nat table is empty.

Anybody have any idea what I'm doing wrong with the routing on the linux box? If people want raw output from tcpdump or something I'm happy to provide it.

Thanks,
Oliver

[Mark McLeod]

It'll be something simple I imagine.
Your VPN gateway is obviously blocking UDP.

Your VPN must support UDP of course.
Perhaps the UDP port is blocked? TCP uses the same port as https, while UDP will be on a different port.

[linuxboy]

I made a few changes (ran iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE) and I can send UDP packets using netcat to things on the VPN. I am at school and the main breaker is off but I will try it when I get home. I'm pretty sure that the VPN gateway doesn't forward UDP broadcast, is that necessary for the FRC control system or should it all direct communication?

Oliver

[Mark McLeod]

No broadcasting or multicasting in the standard FRC robot network.
It's all unicast one-to-one.

[linuxboy]

No broadcasting or multicasting in the standard FRC robot network.
It's all unicast one-to-one.

Sounds good.
Would having MASQUERADE in the nat table influence whether or not it works? I had to add it to get online through the VPN. To be honest I'm not quite sure why I had to add it to get online, or quite what it does.

Oliver

[Mark McLeod]

I'm not sure how MASQUERADE is used in your context, but in general Masquerading is how we talk from a device on a private network to the public Internet, also known as Network Address Translation. I doubt it will affect your internal UDP traffic, but iptables would get tricky without a two-way conversation and packet forwarding may get weird.

Using a typical home network as an example, via DHCP all the devices are given a private IP network address. By convention, none of these addresses are allowed through a Gateway out on the Internet. That's because the private IP address your computer uses is the same private IP address your next door neighbor is using and the Internet would have no way to route any responses back to the proper house.
The way around this is a normal function of the Gateway where it masquerades as the machine originating the IP traffic. It knows who you are, it has a valid public IP address, and it pretends the IP traffic is really coming from it. It acts as a clearing house between public and private networks.

[linuxboy]

Does that change the source for the UDP packets? I'm thinking its possible that the responses are addressed to the VPN gateway instead of the machine and therefore it does not send them on to the machine running the DS.

Oliver

[Mark McLeod]

I just did a search and these Linux IP Masquerade HOWTO (http://tldp.org/HOWTO/IP-Masquerade-HOWTO/) (the bible) and Configuring IP Masquerade (http://tldp.org/LDP/nag2/x-087-2-masq.configuration.html) documents might help.

You could experiment with turning it off long enough to get a version of UDP working, then work your way back to reestablish your Internet connection.
A Gateway should really only be employed between you and the Internet. It shouldn't normally be part of your internal networking. That may be confusing things.