Source NAT rewrite but through OpenVPN connection



  • Hi guys,

    I have an OpenVPN server running on my pfSense, so I can VPN to my house from my phone and access services on my local subnet.  The routing works great and I can ping all devices on my local LAN when connected via VPN.

    One of the devices on my LAN needs to have connections appear to come from the same subnet, otherwise, it doesn't work.  I'd like to know if there's a way to do a NAT source rewrite on packets coming from my VPN-connected phone but over the VPN tunnel.  Here's a quick diagram of what happens now and what I'd like:

    Currently:

    PHONE (VPN IP 10.56.0.6 appears to LAN device as 10.56.0.6) –->  INTERNET/VPN TUNNEL ---> pfSense (10.50.1.1/16) --> LAN device (10.50.20.1)

    Would like:

    PHONE (VPN IP 10.56.0.6 appears to LAN device as 10.50.30.1) --->  INTERNET/VPN TUNNEL ---> pfSense (10.50.1.1/16) --> LAN device (10.50.20.1)

    Is it possible to do this?  I've tried everything in my manual outbound NAT rules.  Tried to do translation after selecting the WAN interface, OpenVPN interface, LAN interface, and no go...

    Thanks!

    Rob



  • The Outbound NAT in pfSense is able to do that, though.

    Ensure, that the outbound NAT is set in manual or hybrid mode.
    Add a rule like this:
    Interface: LAN
    protocol: any
    source: <vpn tunnel="" network="">destination: <the lan="" ip="" of="" the="" problematic="" device="">translation: interface address

    That should work for you.

    BTW: a /16 LAN network?  :o
    More than 32000 devices at home?</the></vpn>



  • @viragomann:

    The Outbound NAT in pfSense is able to do that, though.

    Ensure, that the outbound NAT is set in manual or hybrid mode.
    Add a rule like this:
    Interface: LAN
    protocol: any
    source: <vpn tunnel="" network="">destination: <the lan="" ip="" of="" the="" problematic="" device="">translation: interface address

    That should work for you.

    BTW: a /16 LAN network?  :o
    More than 32000 devices at home?</the></vpn>

    Thanks virago :)

    Yup, so it looks like it was working all along – I tested it with a Linux machine where I could tcpdump to see the source IP.

    It seems that the device wants more than just local LAN source IP to work.  I wonder what? :P Some kind of multicast thing -- my knowledge gets hazy at that point.

    As for a /16 LAN at home.  hehe.  So there's a couple reasons for that.  I run a business from home and often connect via VPN to my clients which are usually on a 192.168.x, but sometimes on a 10.x, and so I want to make sure I have no subnet conflicts (I realize I could do 192.168.178.x or something obscure).  But I do have about 100+ devices on my home network so I like to organize them in logical subnets, and I just like remembering addresses like 10.50.1.30 vs. 192.168.17.83 :)


  • LAYER 8 Netgate

    As for a /16 LAN at home.  hehe.  So there's a couple reasons for that.  I run a business from home and often connect via VPN to my clients which are usually on a 192.168.x, but sometimes on a 10.x, and so I want to make sure I have no subnet conflicts (I realize I could do 192.168.178.x or something obscure).

    Yeah, large swaths to 10. addresses are usually what you avoid if you are trying to eliminate subnet conflicts over VPNs but if that works for you…


Log in to reply