OpenVPN Conflicting Subnetting Issues



  • Hi all, first post here on the forums.

    I have a question in regards to the OpenVPN configuration on my pfSense 2.0.2 machine.
    Me issue is that the internal network I use on my pfSense machine (192.168.1.0/24) conflicts with some of the networks I use to connect to our VPN. I was able to go into the properties of my PPTP connections and untick "Use default gateway on remote network", which would allow me to have the VPN connection (192.168.1.0/24) and the local network (192.168.1.0/24) coexist, how am I able to do so with OpenVPN?
    I had set the PPTP server to use 192.168.1.210 onwards with 16 clients; the DHCP range was 192.168.1.100-200 so it was no issue.
    Now, I've got the OpenVPN server set to use the 10.1.1.0/24 network and route traffic between that and the internal 192.168.1.0/24 network; as soon as I connect an OpenVPN client that resides in a 192.168.1.0/24 network, they lose network connectivity completely (both local and remote, conflicting subnets).

    Hope this made some sense, I'm not very good at laying out questions haha.

    Cheers, kane.



  • The pragmatic fix is to change your pfSense LAN side to a private subnet that "no-one" (except Murphy) is likely to use. e.g. get right away from 192.168.n.n - use 10.n.n.n - e.g. 10.142.87.0/24 (I picked a few "random" numbers). It will then be most unusual that some unfortunate client laptop finds itself in a matching piece of private address space for its local LAN.



  • @phil.davis:

    The pragmatic fix is to change your pfSense LAN side to a private subnet that "no-one" (except Murphy) is likely to use. e.g. get right away from 192.168.n.n - use 10.n.n.n - e.g. 10.142.87.0/24 (I picked a few "random" numbers). It will then be most unusual that some unfortunate client laptop finds itself in a matching piece of private address space for its local LAN.

    Is there no other way around this with OpenVPN like there is with the PPTP settings?

    Kane.



  • well, i have 1 site where exactly the same issue presented itself.

    I worked around it by doing a "virtual" 1:1 NAT on the lan subnet for clients connecting to the vpn

    lan subnet: 192.168.1.1/24
    virtual subnet: 192.168.231.1/24

    so when openvpn makes a connection to 192.168.231.10 the pfsense 1:1 NAT translates this to 192.168.1.10

    i can't remember the details exactly, but if you can't figure it out, then i can allways login to that site and check out what exactly i did there  :-)



  • @heper:

    well, i have 1 site where exactly the same issue presented itself.

    I worked around it by doing a "virtual" 1:1 NAT on the lan subnet for clients connecting to the vpn

    lan subnet: 192.168.1.1/24
    virtual subnet: 192.168.231.1/24

    so when openvpn makes a connection to 192.168.231.10 the pfsense 1:1 NAT translates this to 192.168.1.10

    i can't remember the details exactly, but if you can't figure it out, then i can allways login to that site and check out what exactly i did there  :-)

    That would be good if you could please my friend, muchly appreciated.



  • right so:

    -get your openvpn tunnel working
    -assign an interface to the tunnel (interfaces–>assign)
    -configure the interface like in the screenshot (ovpn_interface.png) & restart your openvpn service
    -add firewall rules on the new openvpn_interface (in my example OVPNRW) to allow traffic
    -create a 1:1 NAT subnet (see nat-overview.png & nat-detail.png | vlan_secnet could/should be replaced by LAN)
    -adjust the routes in your openvpn server config to match the created 1:1 subnet (ovpn_server_config.png)
    -save and restart openvpn server
    -try

    you can/should adjust the subnetting to your situation.
    now a vpn-client should now be able to connect to a host on a conflicting subnet using the 1:1 subnet we created.
    192.168.46.10 = 192.168.1.10
    192.168.46.100 = 192.168.1.100

    i hope this makes sense somehow :)










  • Save yourself several hours (or days) of trying to troubleshoot how to NAT the traffic traversing the tunnel… and just adjust your LAN subnet accordingly.  There are literally thousands of options... if you're going to run a VPN server or connect to a VPN... you should not be running 192.168.0.0/24 or 192.168.1.0/24 on your LAN.

    e.g.... While heper's solution is creative, I would say instead of trying to translate 192.168.46.x back to 192.168.1.x as a workaround for a flawed setup.... just set your LAN to 192.168.46.0/24... and be done.



  • @marvosa:

    Save yourself several hours (or days) of trying to troubleshoot how to NAT the traffic traversing the tunnel… and just adjust your LAN subnet accordingly.  There are literally thousands of options... if you're going to run a VPN server or connect to a VPN... you should not be running 192.168.0.0/24 or 192.168.1.0/24 on your LAN.

    This. The fact PPTP actually worked in such a circumstance is surprising, it has the same complications with that as any other routed VPN. The NAT is just a headache that's unnecessary, change to a little-used subnet and be done with it.



  • i agree with marvosa & cmb that nat is not the ideal solution ….

    but i also realise that changing a lan-subnet can be a lot of work or even impossible if the company does not want to change the lan-subnet for whatever reason.



  • Thanks for all your help guys, I appreciate the answers.

    I considered using heper's solution but for the sake of avoiding all conflicts I think I might just change the addressing scheme to something somewhat random like 10.9.8.0/24 or something similar.


Locked