Client not getting /32 route to pfSense
-
First time using OpenVPN, setup wasn't too bad. Even managed to get it working with AD/LDAP authentication without too much trouble. However, I'm running into a bit of a roadblock.
If I set the Gateway Redirection, everything works as expected. The client gets a /32 route to the VPN server and all other traffic is routed over the VPN connection.
What i need to do though, is push only our local routes, including a /24, which happens to include the /32 assigned to pfSense. When doing this, all routes show up in the client as expected, but there is no /32 route to the pfSense IP, which effectively renders the VPN connection useless.
Is there a way to do this?
Thanks!
-
There's no such thing as a /32 route. The longest possible is /31 and some operating systems don't like that, so you'd then use /30. /32 is only used to identify an interface. It's not commonly used with IPv4, but /128 is commonly used with IPv6.
-
Thanks for taking a look, but you might want to take a refresher course on networking. /32 routes are very common.
Personally, I've been using /32 routes since learning fun things like OSPF and BGP some 25 years ago. There are probably folks around here who've been doing it even longer than that.
I'm going to go out on a limb, and guess that you'd also state that you can't use .0 for a host address too. Check this out... showing you some /32 routes in a production network. In this case, the /32 route announcements via OSPF are absolutely necessary for carrying VPLS/MPLS traffic on one of the wireless networks I operate.
[troy@washington ~]$ telnet 172.17.4.0 Trying 172.17.4.0... Won't send login name and/or authentication information. Connected to 172.17.4.0. Escape character is '^]'. User Access Verification Username: troy Password: COLO_SW01#sh ip route | inc 172.17.85 O 172.17.85.192/26 O 172.17.85.193/32 O E1 172.17.85.71/32 O E1 172.17.85.41/32 O E1 172.17.85.42/32 O E1 172.17.85.61/32 O E1 172.17.85.51/32 O E1 172.17.85.1/32 O E1 172.17.85.31/32 COLO_SW01#quitFWIW, I was not the original architect of this network. I'd have never used 172.17.4.0 for a router IP, even though it does work perfectly fine.
Anyways, back to the question at hand. Here's the routing table from Windows10 after logging into OpenVPN. As you can see, on the 3rd line, the client is installing a /32 route to the VPN server.
IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.109 35 0.0.0.0 128.0.0.0 172.23.240.1 172.23.240.2 281 128.0.0.0 128.0.0.0 172.23.240.1 172.23.240.2 281 xx.yy.zz.2 255.255.255.255 192.168.0.1 192.168.0.109 291Now, I do not want all traffic to pass through the VPN, but if I advertise the /24 that pfSense is on, the network breaks, as there is no longer a valid route to the VPN server itself.
IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.109 35 xx.yy.zz.0 255.255.255.0 172.23.240.1 172.23.240.2 281Since the OpenVPN server is in the advertised subnet, it should install a /32 route to preserve connectivity.
-
I'm not familiar with BGP, but with OSPF, that address is to set the router ID and nothing else. You'd still have addresses on the interfaces to carry the traffic. The router ID can be specifically configured or use the highest loopback of interface IPv4 address. You get the same on IPv6, even without OSPF or BGP. For example, my WAN address is a /128, but that is not used for routing. However, it can be used as a destination address for connecting to my network via VPN etc. Like the router ID, that /128 address can be routed to. On the other hand, the actual routing is done via the link local address, so if I wanted to connect my VPN, the packets would be routed to that /128 via the link local address. Also stop to think about how networks work. When one device wants to communicate with another, the first thing it has to do is determine whether the destination is on the LAN or not. That is done with the subnet mask and comparing the destination with the local address. This means that if the destination is not within the subnet range, then it's not on the local network. With a /31, you could have 2 hosts and can directly communicate between them. With a /32, there is only one host, which means every other possible address is not local and must be reached by routing. In your post you said "including a /24, which happens to include the /32 assigned to pfSense". Well, you're creating a situation where you have 2 different subnet masks on the same network for an address and a VPN that can't communicate on it's own.
BTW, my OpenVPN configuration requires different addresses for each end, both IPv4 and IPv6. You can't do that with a /32 or /128.
-
Apples and oranges man. I'm talking about a ROUTE, you're talking about an interface IP. Yes, some routers and operating systems have issues assigning and using a /32 on an interface for routing purposes. I'm not talking about that in any way, shape, or form. I'm talking about the actual route itself, which should point to the gateway. See my previous post for the example.
Better yet, just try it yourself... Check the option for "Redirect IPv4 Gateway" and see what your routing table looks like. This is how every VPN connection works. They MUST provide a /32 route to the VPN server in order to maintain connectivity when the tunnel is up.
The exception to this rule, is when you're using split tunneling, in which case, the VPN server advertises routes to the client, which the client then adds to the local routing table. The problem is that I need to advertise a larger network that includes the IP of the VPN appliance itself, which breaks connectivity since the /32 route isn't being created.
And yes, even Windows can handle a /32 route, so if my VPN server is 8.8.8.8, but is advertising the entire 8.8.8.0/24 network, I would need the more specific route. This is what is not happening with OpenVPN.
C:\WINDOWS\system32>route add 8.8.8.8/32 192.168.0.1 OK! C:\WINDOWS\system32>route print 8* IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 8.8.8.8 255.255.255.255 192.168.0.1 192.168.0.109 36 ===========================================================================I do not know if this is an issue with how it's implemented by Netgate or if it's an upstream issue. I'm attempting to use pfSense as a VPN appliance, so I'm starting here.
-
Yeah that's a host route. So yes, /32 (host) routes exists. What's that to do with the original problem?
What i need to do though, is push only our local routes, including a /24, which happens to include the /32 assigned to pfSense. When doing this, all routes show up in the client as expected, but there is no /32 route to the pfSense IP, which effectively renders the VPN connection useless.
I'd need to see your OVPN configuration, but that's not how OVPN is configured per default. It doesn't push a /32 to a client. It runs either in subnet mode - then it's the CIDR of your tunnel network (normalls sth like 10.0.8.0/24) - or it's running in the old /29 style mode where every client got it's own "personal" gateway and the tunnel network was split into multiple /29s.
So there's no /32 to find. If your tunnel network you defined for dial-in is part of a larger route you are pushing there should be no problem. We're using a /24 for our office dial in while we push the big/8 (for easier and less routes to push) network, too. So I don't really get what you are trying to do / are doing exactly having a /32 assigned?
They MUST provide a /32 route to the VPN server in order to maintain connectivity when the tunnel is up.
Eh, no they don't. They need to do this with a full route-through-vpn style VPN but actually they are doing it by using 0.0.0.0/1 and 128.0.0.0/1 and set those to route through the VPN link. So they leeave the default GW (0.0.0.0) untouched, add a host route to the VPN service IP via default and add those 2 /1 routes to route everything else through the tunnel.
But without the full-tunneling, there's no need for a /32 to the VPN gateway. -
Ok, so I re-worked my config to avoid using public IPs. No, there's no smoke and mirror stuff going on. I AM the ISP, and the world is my lab.
C:\WINDOWS\system32>tracert -d 172.23.23.2 Tracing route to 1zz.23.23.2 over a maximum of 30 hops 1 1 ms <1 ms 2 ms 192.168.0.1 2 25 ms 29 ms 37 ms xx.yy.aa.33 3 55 ms 21 ms 23 ms xx.yy.aa.241 4 41 ms 44 ms 22 ms xx.yy.zz.73 5 49 ms 46 ms 52 ms 172.23.23.2 Trace complete. C:\WINDOWS\system32>tracert -d xx.yy.zz.4 Tracing route to xx.yy.zz.4 over a maximum of 30 hops 1 1 ms <1 ms 2 ms 192.168.0.1 2 26 ms 37 ms 38 ms xx.yy.aa.33 3 24 ms 23 ms 37 ms xx.yy.aa.241 4 32 ms 29 ms 23 ms xx.yy.zz.73 5 43 ms 45 ms 30 ms xx.yy.zz.2 Trace complete. C:\WINDOWS\system32>Server Config
dev ovpns1 verb 1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp4 cipher AES-128-CBC auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown client-connect /usr/local/sbin/openvpn.attributes.sh client-disconnect /usr/local/sbin/openvpn.attributes.sh local 172.23.23.2 tls-server server 172.23.240.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc/server1 verify-client-cert none username-as-common-name plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so /usr/local/sbin/ovpn_auth_verify_async user T3BlblZQTg== false server1 1194 tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'vpn.mydomain.com' 1" lport 1194 management /var/etc/openvpn/server1.sock unix max-clients 50 push "route 172.23.23.0 255.255.255.0" push "route 100.64.0.0 255.252.0.0" push "dhcp-option DOMAIN mydomain.com" push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 8.8.4.4" ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.2048 tls-auth /var/etc/openvpn/server1.tls-auth 0 ncp-ciphers AES-128-GCM persist-remote-ip float topology subnetClient Config:
dev tun tun-ipv6 persist-tun persist-key cipher AES-128-CBC ncp-ciphers AES-128-GCM auth SHA256 tls-client client resolv-retry infinite remote 172.23.23.2 1194 udp4 auth-user-pass ca vpn-UDP4-1194-ca.crt tls-auth vpn-UDP4-1194-tls.key 1 remote-cert-tls serverRouting table when connected
IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.109 35 100.64.0.0 255.252.0.0 172.23.240.1 172.23.240.2 281 127.0.0.0 255.0.0.0 On-link 127.0.0.1 331 127.0.0.1 255.255.255.255 On-link 127.0.0.1 331 127.255.255.255 255.255.255.255 On-link 127.0.0.1 331 172.23.23.0 255.255.255.0 172.23.240.1 172.23.240.2 281 172.23.240.0 255.255.255.0 On-link 172.23.240.2 281 172.23.240.2 255.255.255.255 On-link 172.23.240.2 281 172.23.240.255 255.255.255.255 On-link 172.23.240.2 281 192.168.0.0 255.255.255.0 On-link 192.168.0.109 291 192.168.0.109 255.255.255.255 On-link 192.168.0.109 291 192.168.0.255 255.255.255.255 On-link 192.168.0.109 291 224.0.0.0 240.0.0.0 On-link 127.0.0.1 331 224.0.0.0 240.0.0.0 On-link 172.23.240.2 281 224.0.0.0 240.0.0.0 On-link 192.168.0.109 291 224.0.0.0 240.0.0.0 On-link 172.17.234.209 5256 255.255.255.255 255.255.255.255 On-link 127.0.0.1 331 255.255.255.255 255.255.255.255 On-link 172.23.240.2 281 255.255.255.255 255.255.255.255 On-link 192.168.0.109 291 255.255.255.255 255.255.255.255 On-link 172.17.234.209 5256 =========================================================================== Persistent Routes: None C:\WINDOWS\system32>ping 172.23.23.1 Pinging 172.23.23.1 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 172.23.23.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), C:\WINDOWS\system32>route add 172.23.23.2/32 192.168.0.1 OK! C:\WINDOWS\system32>ping 172.23.23.1 Pinging 172.23.23.1 with 32 bytes of data: Reply from 172.23.23.1: bytes=32 time=43ms TTL=63 Reply from 172.23.23.1: bytes=32 time=31ms TTL=63 Reply from 172.23.23.1: bytes=32 time=49ms TTL=63 Reply from 172.23.23.1: bytes=32 time=44ms TTL=63 Ping statistics for 172.23.23.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 31ms, Maximum = 49ms, Average = 41ms C:\WINDOWS\system32>Note, that OpenVPN is pushing a route to 172.23.23.0/24 as expected, but it's not carving out a host route to 172.23.23.2, which results in no traffic being able to pass over the tunnel.
Once I add the /32 route manually, traffic does flow. Now, this isn't a problem for ME, but it is a problem for those people who can barely figure out how to do a Google search for "what is my ip."
Some things to note:
- Yes, I'm runng pfSense inside my network rather than at the border. I'm hoping it will function well as a VPN appliance.
- Yes, I could roll my own OpenVPN server, but at what cost?
- No, putting pfSense at my border is not an option.
- Yes, simply routing ALL traffic over the VPN is an option, but it's less than desireable.
And, just to be complete, here is the WAN/Gateway config from pfSense:
<interfaces> <wan> <enable></enable> <if>hn0</if> <descr><![CDATA[WAN]]></descr> <ipaddr>172.23.23.2</ipaddr> <subnet>24</subnet> <gateway>WANGW</gateway> <spoofmac></spoofmac> </wan> </interfaces> <gateways> <gateway_item> <interface>wan</interface> <gateway>172.23.23.1</gateway> <name>WANGW</name> <weight></weight> <ipprotocol>inet</ipprotocol> <descr><![CDATA[Test]]></descr> </gateway_item> <defaultgw4>WANGW</defaultgw4> </gateways>Thanks!
-
@4xTroy said in Client not getting /32 route to pfSense:
Once I add the /32 route manually, traffic does flow. Now, this isn't a problem for ME, but it is a problem for those people who can barely figure out how to do a Google search for "what is my ip."
I'm trying to understand why you need a /32. While you can set up a route, it's not part of the normal OpenVPN config. When I set up OpenVPN, I had to provide the 2 tunnel end point addresses and my public IP address, so that I could reach the VPN, but there was certainly no need for a /32 address. If you are trying to route to a /32, it has nothing to do with OpenVPN, other than it's the path the packets pass through. Routing through a VPN is no different that through any other IP connection.
-
I can only answer with a question... Why do we need a /32 route when using the gateway redirect?
IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.109 35 0.0.0.0 128.0.0.0 172.23.240.1 172.23.240.2 281 128.0.0.0 128.0.0.0 172.23.240.1 172.23.240.2 281 xx.yy.zz.2 255.255.255.255 192.168.0.1 192.168.0.109 291Fire up a session, then delete that /32 route to your VPN server and see what happens.
Again, if pfSense has an address, say 123.45.67.89/24, and needs to push a route to 123.45.67.0/24, the routing table should look something like this:
IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.109 35 123.45.67.0 255.255.255.0 172.23.240.1 172.23.240.2 281 123.45.67.89 255.255.255.255 192.168.0.1 192.168.0.109 291Without that /32 route, the tunnel will be inoperable. Again, I do not know if this is a pfSense issue or an OpenVPN issue.
-
My OpenVPN tunnel works fine without doing that. I only have "push "route 0.0.0.0 0.0.0.0";push "route-ipv6 ::/0"" in Additional configuration options.
