Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Source NAT rewrite but through OpenVPN connection

    Scheduled Pinned Locked Moved NAT
    4 Posts 3 Posters 564 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Z
      zax123
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • V
        viragomann
        last edited by

        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>

        1 Reply Last reply Reply Quote 0
        • Z
          zax123
          last edited by

          @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 :)

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            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…

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.