Solved OpenVPN + NAT + routing

F

free-and-bsd

Hi, everyone. Seems like between the times I DO the PF config, I forget something very important :)

Anyway. My box has 3 NICs. There is WAN and LAN ethernets, then there is a WIFI AP managed by hostapd. And here is my /etc/pf.conf:
Code: 
out_if = "igb0"
lan_if = "igb1"
wifi_if = "wlan0"

nonroute = "{ 0.0.0.0/8, 20.20.20.0/24, 127.0.0.0/8, 172.16.0.0/12, 169.254.0.0/16, 192.0
.2.0/24, 192.168.0.0/16, 224.0.0.0/3, 255.255.255.255 }"

icmp_types = "{ 0, 3, 8, 11, 12 }"

set optimization aggressive
set block-policy return
set skip on lo0
scrub in all fragment reassemble no-df max-mss 1440

nat on $wifi_if from ! $wifi_if:network to any -> ($wifi_if)
nat on $lan_if from ! $lan_if:network to any -> ($lan_if)
nat on $out_if from ! $out_if:network to any -> ($out_if)

anchor openvpn
anchor openvpn_server1
antispoof quick for { $out_if $lan_if $wifi_if }

block drop in quick on $out_if from $nonroute to any
block in on $out_if all
pass quick on $wifi_if all
pass quick on $lan_if all
pass in quick on $out_if inet proto icmp all icmp-type $icmp_types
pass out quick all
block  all
A very simple one, I simplified it on purpose. So is there anything wrong with it?
Notice, I purposefully created equal rules for all interfaces except the WAN ($out_if). There isn't a SINGLE rule for $lan_if that doesn't exist for $wifi_if.
Then how can it be that I can ping hosts connected to Wifi from LAN, but I can't ping LAN from any Wifi connected host?
I can also ping the $out_if interface address (and Internet in general, of course) from my WLAN computer. It is only LAN interface and network that cannot be pinged!
What can be the possible reason? Does WLAN behave in some way differently from LAN?

Actually, I originally wanted it to be exactly this way: wifi clients can connect but can't access LAN. While LAN clients can access everything. But yesterday I just couldn't make it by ANY means possible. WLAN connected client had immediate access to LAN. Now today I change a little something in there, and OH I can't make it work again this way :))))))))

So maybe this is the behaviour I wanted. But now I want to know WHY. It seems terribly weird to me. And this is not the first PF firewall that I'm managing.
 
Additionally, my LAN host is configured to allow ping packets. It can very well be pinged from the PF machine in question. Just for some obscure reason complete LAN address pool can't be pinged from WLAN, and I wanna know why. The instant reply is "no route to host". Of course, adding route by route command (tried that as well) gives reply "route already in the table". So it's the PF machine that blocks it somehow.
 
It was a stupid problem indeed. I had an ethernet NIC on the WLAN-connected machine, which was assigned a static address precisely in that space of 192.168.8.0/27. Just in case I should connect that one to the cable here...
How embarrassing ?
 
Well, I still have similar problem on that machine, though my MAIN question above proved to be my own mistake. Still.

This same machine runs OpenVPN client connecting it to a remote network. That adds 2 routes: OpenVPN network 10.0.2.0/24 and remote LAN , say, 192.168.5.0/24. The purpose is to connect my LAN attached to this machine to that remote LAN.

Anchor 'openvpn' above dynamically adds NAT for those new routes in connection with tun4 interface the same way NAT is defined in my config above. Nothing fancy, just basically what is supposed to be needed to allow and NAT all the traffic there. Of course, OpenVPN server-side config option push "route {IP} {MASK}" adds those routes remotely. This /etc/pf.conf.vpn takes care of the local part:
Code: 
nat on tun4 from ! tun4:network to tun4:network -> (tun4)
pass quick on tun4 all
This pretty much covers everything NOT covered in the config in the OP.

Still... I'm left with the same question: why is it that those remote routes (10.0.2.0/24 and 192.168.5.0/24) are only available on any LAN machine but not to any WLAN machine??? It's about the same question, but with no such foolish blunder. I hope :D :D
 
Hmmmm... Thought it might depend on the OpenVPN server configuration.
Its config contains following directives regarding routing:
Code: 
...
route 192.168.5.0 255.255.255.224
...
(which is my LAN)
And client config accordingly has
Code: 
ifconfig-push 10.0.2.15 255.255.255.0
iroute 192.168.5.0 255.255.255.224
(again, propagating my LAN to the OpenVPN server and claiming fixed address 10.0.0.15.)
So, my LAN is known to the OpenVPN server while my WLAN is not. That may be why I can access OpenVPN server-side networks from LAN, but not from WLAN.
What makes me think so is the fact that client-side VPN address 10.0.2.15 can be pinged from WLAN, but not the rest of the VPN-related routes.

But that seems strange to me... The problem I"m talking about is to forward the routes available on one machine to a LAN linked to that machine (WLAN). Much like forwarding default gateway to linked LANs. What has that to do with the remote gateway machine?
 
OK, my first description was a bit insufficient. Let's do it again.
Here are the routes available on my machine that has LAN, WLAN, WAN and OpenVPN (connected as a client) links:
Code: 
netstat -r
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            (ISP gateway)      UGS        igb0
10.0.2.0/24        10.0.2.1           UGS        tun4
10.0.2.1           link#5             UH         tun4
localhost          link#5             UHS         lo0
.....
192.168.5.0/24     10.0.2.1           UGS        tun4
192.168.7.0/27     link#4             U         wlan0
192.168.7.1        link#4             UHS         lo0
192.168.8.0/24     link#2             U          igb1
localhost          link#2             UHS         lo0
So, all the needed routes ARE available on this machine.
Apart from what OpenVPN server knows, what prevents WLAN machines from having these same routes?
However, even adding them explicitly on my WLAN-connected machine by command route add -net 10.0.2.0/24 192.168.7.1 doesn't make it work. Route gets added, but 10.0.2.1 server address still cannot be pinged. Same goes for the network 192.168.5.0/24 that is accessible via 10.0.2.0/24.

OK, OpenVPN server does not know about my WLAN subnet. But does it have to? After all, those addresses get translated on this machine in question by NAT rule nat on tun4 from ! tun4:network to tun4:network -> (tun4). Or do I need additional NAT translation rules for the whole thing to work as intended?

As I picture it to myself, THIS machine (LAN + WLAN + WAN + VPN) acts as a router for LAN and WLAN accordingly.
So I charge it with forwarding packets from WLAN to networks available via VPN. As a router, then, it should send those packets as though coming from itself (NAT) and then resend the reply back to WLAN. Isn't that what a router does? OpenVPN router doesn't even need to know WHERE those packets are coming from, THIS router takes care of that. Then why doesn't it work?
 
are you sure nat works ?
the symptoms are like it's not working
so your wlan subnet sent packets reach openvpn server but it does not now how to reply
no route/iroute for 192.168.7.0
if nat is working you don't need any route/iroute
 
covacat said:
are you sure nat works ?
the symptoms are like it's not working
so your wlan subnet sent packets reach openvpn server but it does not now how to reply
no route/iroute for 192.168.7.0
if nat is working you don't need any route/iroute
Click to expand...
As I see it, openvpn server receives packets from my HOST. So it needs to reply to the HOST. And the NAT work is done by the host , isn't it??
 
Sure, it all started working as soon as I added route/iroute 192.168.7.0/27 to the server and ccd/client. But that's not exactly my question :)
 
Look. There may be many other networks willing to send packets to that VPN. Does the openvpn server need to know about them all? No, that's what the router is for. And the router is my HOST.
So, yes, OpenVPN server knows how to handle routes. But doesn't my host also know that?
 
covacat said:
are you sure nat works ?
the symptoms are like it's not working
so your wlan subnet sent packets reach openvpn server but it does not now how to reply
no route/iroute for 192.168.7.0
if nat is working you don't need any route/iroute
Click to expand...
Is nat on tun4 from ! tun4:network to tun4:network -> (tun4) not enough to cover the NAT part? Manuals and other sources assure me that it is. It means, all the packets that get to tun4-linked network will have the proper address translation.
Then the openvpn server (on the other end of the tunnel) will only have to REPLY to those packets that come from tun4 end of it. Then the tun4 host will take it from there, will it not? Or am I missing something?
 
Or is there a rule that on the host where a VPN tunnel is open all routing related to that VPN is handled by the VPN server side? So that the host's own routing mechanisms don't interfere in that particular case? Kind of agreement upon the separation of responsibilities?
 
routing should work as usual for openvpn
just tcpdump on the server side while you ping openvpn servers end from 192.168.5.x or 7.x
look at the packets addresses and see if nat work or not
tcpdump -i tunX -nl icmp (on the openvpn server box)
if you see 192.168.5/7 source addresses nat is not working
 
covacat said:
ipsec esp tunnels work by policy based rules/routing, without routing table / interfaces etc but it's not the case here
Click to expand...
Educated myself on this a bit. And you know what? My personal opinion, of course. The bigtime IT guys who write documentation know better... Then there is this strictly professional attitude that I"m well familiar with: stuff must not appear easy and simple! Take your time to make it out by yourself -- this time will be well spent. Good, I agree.
But when it comes to documentation, should this not be reflected / mentioned somewhere in the documentation OTHER than the industry standards? I mean manuals & HOWTOS. Like FreeBSD Handbook chapter on routing.

Why? Because, taking OpenVPN as an example, these progs create networking interfaces. And these (tun tap plip ppp eth whatever) are made to appear similar for good practical reasons. Just how similar? Well, firewall rules, for example, make little difference between these. Very handy...
But then one would also logically conclude that ROUTING is also done the same way for everything that appears to behave like a networking interface. Really, why no?? But no.

Yet I never found any mentioning of this in any user-level (ok, HOWTO level) documentation...
 
You must log in or register to reply here.
Back
Top