Linux Routing in presence of VPN - Accessing router across a firewall appliance?

0

I don't know a lot about network routing. Hopefully this is easy.

  1. I have my ISP-provided router providing IP's via DHCP on 192.168.10.0/24
  2. That's connected to the "red" interface of a Nethserver (firewall appliance)
  3. The Nethserver's "green" interface provides IP's via DHCP to the LAN on 192.168.100.0/24
$ ip route # on the firewall    
default via 192.168.10.1 dev em1     
192.168.10.0/24 dev em1 proto kernel scope link src 192.168.10.10    
192.168.100.0/24 dev p2p2 proto kernel scope link src 192.168.100.1  
  1. The laptop on the 192.168.100.0/24 network is connected to a VPN
$ ip route # on the laptop
default via 10.8.8.1 dev tun0  proto static  metric 50 
default via 192.168.100.1 dev enp0s25  proto static  metric 100 
10.8.8.0/24 dev tun0  proto kernel  scope link  src 10.8.8.27  metric 50 
169.254.0.0/16 dev tun0  scope link  metric 1000 
192.168.100.0/24 dev enp0s25  proto kernel  scope link  src 192.168.100.10  metric 100 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 linkdown 
209.X.Y.Z via 192.168.100.1 dev enp0s25  proto static  metric 100 

I will get that router out of there at some point, but for now I want to be able to get from my laptop to the web interface of that router at 192.168.10.1. How do I add something to the routing table to do that?

(Bonus points: A not-too-long reference that will help me understand at least the basics of network routing.)

Diagon

Posted 2019-06-08T17:44:46.610

Reputation: 598

Answers

0

Very short explanation of routing: Giving a destination address, the kernel consults the routing table(s) to find out which interface to use for the next hop. You can use ip route get 1.2.3.4 to see the results of that lookup for destination address 1.2.3.4.

You already found ip route, which is equivalent to ip route list, and you can use ip route add ... and ip route del ... to add and delete rules.

However, from your routing table, and assuming that your laptop has a default route to 192.168.100.1, everything should work. If it doesn't, it's not the routing which is at fault.

To debug this, open three terminals (one on your laptop, two on the Nethserver appliance, however you get onto this one), and do tcpdump -ni em1 and tcpdump -ni p2p2 on the Nethserver, and similar on your laptop with whatever the correct network interface is.

Then do ping 192.168.10.1 on your laptop, and watch how far the ping packets (and the response) gets. That will let you narrow down where the problem is.

For example, if you see outgoing packets on p2p2, but not on em1, the firewall doesn't allow traffic from p2p2 to em1. If you see response packets at em1, but not at p2p2, the connection tracker in the firewall which should let through answers for established connections doesn't work. And so on.

Edit

As your default route is not pointing to the Nethserver (but, in your case, to the VPN), you have to tell you laptop that it can reach the 192.168.10.0/24 via the Nethserver (and shouldn't try to reach it via the VPN).

To do that, you add (as root) a route on your laptop:

ip route add 192.168.10.0/24 via 192.168.100.1 dev enp0s25

(there are some variants of this command that will also work, experiment a bit).

So in this case open four terminal windows for the tcpdump, two on your laptop on tun0 and enp0s25.

ping away and look at where the packets go; add and delete a few routes and see what changes. Following packets is really the best way to understand networking.

Try to minimize other traffic during this; if you still have too much traffic, read up on filter rules for tcpdump (or use wireshark on the interface(s) with too much traffic; you can set filter rules in a UI with that).

Edit

Yes, you can make this setting persistent in various ways (including post-up) depending on your setup, but the most elegant way is to have the Nethserver distribute that additional route via DHCP to the 192.168.100.0/24 subnet. In that way, all machines in the subnet will receive the route, without having to explicitely configure all of them. You will likely need to edit the DHCP configuration file on the Nethserver to achieve this.

dirkt

Posted 2019-06-08T17:44:46.610

Reputation: 11 627

Ah! Ok, i'll do all that just for the edification, but I just tried with another laptop and I realized the issue ... I'm behind a VPN. (Somehow I had thought that shouldn't effect local IP blocks, but obviously that's wrong ...) I'll add that to my question, but how can I add a route for the router in this context of the VPN? – Diagon – 2019-06-08T18:22:45.623

That works! Now I think from my other reading, to make it persistent, I have to add this to /etc/network/interfaces as post-up ip route add 192.168.10.0/24 via 192.168.100.1 dev enp0s25. Many thinks. I'll also poke around for more reading. – Diagon – 2019-06-08T20:09:36.107

1

The issue you are having is that all traffic not destined for 192.168.100.* is going out the VPN (because you have 2 default gateways and the VPN one has a lower metric). All you need to do is add a route saying that 192.168.10.* (or even just 192.168.10.1 for tighter security ) should go out the WAN port. I would add a rule like

   route add 192.168.10.1 gw 192.168.100.1

@DirkT rule should work equally well.

davidgo

Posted 2019-06-08T17:44:46.610

Reputation: 49 152

It appears that should be ip route add 192.168.10.1 via 192.168.100.1, and that works! I'll fix it. – Diagon – 2019-06-08T20:05:49.513

@diagon I'm pleased that the ip route command worked for you. I do note that the route add command I provided, while functionally equivalent is not same as it uses a different tool, and my syntax for it is correct. – davidgo – 2019-06-08T22:52:55.027

1Note that the route command is the older tool, and ip route ... the newer tool. Not all current features of Linux routing are accessible using route, so use of ip route ... instead is recommended (though it still works). – dirkt – 2019-06-09T04:29:44.243

Ah, somehow I was thinking that route was just short for ip route. Thanks for the clarification. – Diagon – 2019-06-10T17:58:42.013