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

    pfSense to bypass CGNat

    Scheduled Pinned Locked Moved General pfSense Questions
    10 Posts 2 Posters 1.7k 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.
    • T
      treii28
      last edited by treii28

      I'm primarily asking this here because I don't know what specifically to search for online. I have a qotom 'test' box (at home) I set up for learning more about pfsense as we are now using it with the help of a third party networking guy as our in-house firewall (at work).

      I recently picked up an AT&T hotspot and managed to get it into bypass/bridging mode and connected it up to the qotom WAN connection thinking I might be able to use this pfsense in my RV when I go camping for my internet. I was also thinking that if I leave my RV on-site for a week or two when I head back home to go to work, I could 'check in' on the RV if I left the hotspot/qotom running. Problem is, AT&T appears to use a CGNat as the address I get via dhcp is a 10.159.*

      I have an openvpn set up in my tp-link archer a7 at home and I usually connect to it using either my phone or my laptop directly. I converted the pfsense from ce to plus and added the ovpn import and it seems to have successfully been able to 'connect' to the tp-link's openvpn server. But that's about where I got lost.

      How can I set it up so the pfsense is able to 'share' or otherwise bridge the tp-link local network onto the pfsense local network, and is it possible to share the other direction so when I head back home, i can see the pfsense/rv LAN from my home lan to get back-into the rv?

      I wasn't sure what to search to find how to configure that type of setup. I don't need anything from the openvpn client to be visible on the internet, but I would like to be able to access the client's network on the server's side if possible.

      SW

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        It's possible to link those at layer 2 so both are in the same subnet but that's generally a bad idea. It's better to add routing to allow access between the subnets.

        So first make sure they are using different local subnets.

        On the pfSense end you need to assign the OpenVPN client instance as an interface and then add a pass firewall rule to the new tab to allow traffic from the subnet at the remote end of the tunnel. Importantly it must be passed there and not on the OpenVPN group tab.

        At the server end you need to add a route and an iroute to the subnet behind pfSense via the pfSense vpn IP. I can tell you how to do that in pfSense but not in the TPLink. It may not be possible.

        Steve

        T 1 Reply Last reply Reply Quote 0
        • T
          treii28 @stephenw10
          last edited by

          @stephenw10

          I've been careful to set up different ip ranges. So what I currently have set up is:

          Home network (tp-link router with openvpn):
          LAN/WLAN: 10.10.10./24
          WAN: mapped with dyndns.org for CNAME record (support in tp-link to update the IP automatically)
          OpenVPN: appears to use a 10.8.0.
          /24

          (proposed) RV network (qotom running pfsense+ and openvpn client):
          LAN: 10.10.20./24 (second ethernet port)
          WLAN: 10.10.50.
          /24 (pcmcia wifi adapter)
          WAN: 10.156.201.*/32 connected to AT&T wireless via ethernet to Netgear Nighthawk M6110 in 'passthrough' mode

          I can see the following routes auto-configured when the pfsense connects to the ovpn:

          Destination     gateway         flags   uses    mtu     interface
          0.0.0.0/1       10.8.0.5        UGS	13	1500	ovpnc1	
          default         10.156.201.173	UGS	0	1500	igb0	
          default         10.8.0.5	UGS	0	1500	ovpnc1	
          10.8.0.0/24     10.8.0.5	UGS	13	1500	ovpnc1	
          10.8.0.5        link#12         UH	10	1500	ovpnc1	
          10.8.0.6        link#4          UHS	11	16384	lo0
          
          T 1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Ok, that should work at the pfSense end.

            However likely the TPlink has no routes/iroutes to 10.10.20.0, 10.10.50.0 via 10.8.0.5. It will need that to send traffic over the VPN.

            T 2 Replies Last reply Reply Quote 0
            • T
              treii28 @treii28
              last edited by

              I set up general rules for the 10.8.0 (wasn't sure if I needed that or not) and the 10.10.10.* networks to have access to LAN. I then played with adding a static route for 10.10.10.*/24 via 10.8.0.5

              I can than ping the tp-link from pfsense on 10.10.10.1 but not from a computer connected to the pfsense. I haven't tried anything the other way yet.

              1 Reply Last reply Reply Quote 0
              • T
                treii28 @stephenw10
                last edited by

                @stephenw10

                Yeah, I figured that - checking there is an 'advanced routing' in the tp-link's network settings. I'm not sure if that will allow what I need or not. Worst case scenario is I set up either a second pfsense or a raspberry pi with openvpn server somewhere behind the tp-link to bridge traffic over. I just wanted to try first with what was there.

                I think i see the first trouble spot though. While I see auto-generated routes in the advanced routing that use interface tun0 to 10.8.0.2, it doesn't give me an option to use that interface when adding my own static routes and there is no option in the openvpn server settings for adding routes. Ugh

                1 Reply Last reply Reply Quote 0
                • T
                  treii28 @stephenw10
                  last edited by

                  @stephenw10

                  Yeah, I think that's the stopping point as far as using the tp-link's openvpn is that it won't let me set more complex routes going the other way.

                  So.... there is another option in there with very few settings for a PPTP vpn -- dunno what that is or if it would do anything I needed.

                  Otherwise, if I were to set up another vpn 'behind' the NAT on the tp-link (which can do port forwarding) and assuming I'd prefer to do that using a raspberry pi if possible, would it be easier/better/more-configurable to use openvpn or a wireguard configuration? (I've been able to set up an openvpn server on a pi and may even still have one configured on the pi that serves as a head for my raid-storage - I've never done anything with wireguard)

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    PPTP was removed from pfSense (as a server) years ago because it's insecure. I would not use that!

                    I would use OpenVPN first at least to prove it out. It's more flexible and much easier to troubleshoot.

                    Personally I would swap out the TPlink for a pfSense box and have the option to do whatever you want. But I am biased. 😉

                    T 1 Reply Last reply Reply Quote 1
                    • T
                      treii28 @stephenw10
                      last edited by

                      @stephenw10
                      I haven't played with wireguard yet so I'm toying with that at the moment on the pi behind the wall. It seems to work fine on my phone going in - I'm connecting remote to home using that machine on the raid as it's connected via ethernet but the wifi isn't in use.
                      I have a feeling I'm going to need to hook up something the other way around and/or with two ethernets as I can't get 'in' to the pfsense/network when it's connected to the hotspot device without something being connected behind it. *(and the pi stopped talking to it's wifi for some reason)

                      but it makes it awkward since that box is the best option I have for installing openvpn/wireguard and thus it's the potential 'gateway' for the pfsense side. It can get confusing when pfsense's wlan 10.10.50.* is connected via the wifi, tp-link's 10.10.10.* is connected via the ethernet and I'm trying to get the pfsense's 10.10.20.* to talk through the hotspot via the vpn back to the 10.10.10.* in the same system!

                      I'm toying with it from work (over the internet) since I will need to do something similar to replace a complex ipsec between our office and the datacenter that is going to be cleaned out in a few months. (doing something more complex to replace the old one would be a waste of time) If i can find something simple that will talk to pfsense and allow two-way routing, it would help me with the rv and work!

                      worst case scenario, I am a wizard with ssh and port forwarding. But since there seems to be vpn w/auto-(re)connect built into pfsense, and since I can probably set up routing through the tunnel, that would be preferred.

                      SW

                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        Yes, there are many ways you could do this. Really having the TP-Link as the main router is restrictions here. If you have something else behind it as a VPN server that creates a local routing problem if it's i the same subnet as hosts that need to connect to the remote VPN subnet.

                        If you can't swap out the TPlink for pfSense then consider what it can do and build anything else around that. If that can do Wireguard it would likely work since Wireguard inherently includes routing.

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