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!



  • @4xTroy

    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.



  • @JKnott

    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#quit
    

    FWIW, 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    291
    

    Now, 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    281
    

    Since the OpenVPN server is in the advertised subnet, it should install a /32 route to preserve connectivity.



  • @4xTroy

    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.

    Here's some info:
    RFC 3021
    RFC 6164



  • 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.


  • LAYER 8 Moderator

    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 subnet
    

    Client 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 server
    

    Routing 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.



  • @JKnott

    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    291
    

    Fire 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    291
    

    Without that /32 route, the tunnel will be inoperable. Again, I do not know if this is a pfSense issue or an OpenVPN issue.



  • @4xTroy

    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.


Log in to reply