OpenVPN client, routes being ignored

sporkme

Yep, same deal.

saytar

Yep, same deal.

You have something to examine the packets INSIDE the vpn…...........NSA maybe? If your sniffing the vpn you won't see anything, think encrypted (not without some really, really expensive hardware software and more smarts than I have)....packets go in......to somewhere..................Check at somewhere end maybe?

sporkme

Upgraded to 2.2.1, same deal.

Very odd, here's more proof that traffic from the LAN is just not being sent over the openvpn interface:


fruitcake:resourceFurniture spork$ ping 10.88.77.37
PING 10.88.77.37 (10.88.77.37): 56 data bytes
36 bytes from 10.240.176.233: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 035a   0 0000  40  01 13a7 10.3.2.41  10.88.77.37

Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3

The error there is from 10.240.176.233, which is a router a few hops out from my cable modem, so clearly this traffic is headed out the WAN connection. I still see the proper routes in netstat output and can ping the same IP from the pfsense console.

cmb

Given the description, you have to be forcing that traffic to the Internet with your policy routing rules.

sporkme

I was seeing the problem with and without the only policy routing I know of (failover gateway) in place. The ICMP error message, that you are correct about. When I removed the failover rule, that behavior stopped, but I still was back where I started - I can see traffic go out the ovpnc3 tun interface, but never see it on the other end.

I'm on to something though. On the server, I cranked the verbosity all the way up on openvpn and saw this:

Apr  3 17:40:47 trunk openvpn[19784]: spork/x.x.x.x:41816 MULTI: bad source address from client [10.3.2.41], packet dropped

With either auto outbound NAT rules enabled or "hybrid" rules that include a manual NAT from the LAN to the remote LAN using the openvpn TUN IP, or manual only NAT rules, I notice that nothing changes - the remote end still sees my LAN IP as the source, not the TUN IP, which is what I see when pinging from the console. Maybe it's just not an option to NAT on the way out - the OpenVPN client interfaces never show up as real "interfaces" in the various config screens where there's an interface selection.

Regarding policy routing, shouldn't creating an OpenVPN client instance auto-generate a LAN rule to deal with that?

Derelict

I think you need to post your LAN rules to get more eyes on them.

sporkme

I've come up with a big of a workaround that seems to work and makes everything a little easier to understand.

I've added a new interface and tied it to the OpenVPN client. In addtion to that, I've added the following rules:

Outbound LAN, set gateway to this new openvpn interface
Outbound NAT, set to manual add a rule that when src is LAN dst is my remote subnets, interface is new openvpn interface, NAT using the openvpn local IP
On far end, add a pf rule to NAT on the openvpn interface's IPs

Very convoluted, but it works. I'm hoping that interface assignment "sticks" across reboots and creating/deleting other openvpn clients.

cmb

The "bad source address from client" means the routing on that instance of OpenVPN generating that log is wrong, it thinks that's not a valid source network for that client. The NAT mess will work around that problem because it hides the real source address, and it will persist regardless of adding/removing/editing OpenVPN instances as those interface identifiers are static, but you should really fix the routing issue and get rid of the NAT.

sporkme

@cmb:

The "bad source address from client" means the routing on that instance of OpenVPN generating that log is wrong, it thinks that's not a valid source network for that client.

Yep, that one was an easy google, if i added an "iroute" statement to the config for this client, that fixes everything up.

@cmb:

The NAT mess will work around that problem because it hides the real source address, and it will persist regardless of adding/removing/editing OpenVPN instances as those interface identifiers are static, but you should really fix the routing issue and get rid of the NAT.

I'd rather not, to be honest. :) While I generally "trust" the remote network I'm going into, I don't trust a totally firewall-bypassed network to network link, so I actually prefer getting NAT involved. I also like only having to think about a single IP when getting traffic back over the tunnel as opposed to getting my home internal /24 into the remote network's routing mesh.

There's probably a better way to do this, but I can't come up with one. It got bad enough that I started thinking of moving to IPSEC, which makes me shudder.

cmb

NAT is not a security mechanism, you can accomplish exactly the same thing with firewall rules and no NAT.