IP Lan Block Migrated - Remote Access cannot get through Firewall Gateway

  • Hello all, I am still getting the hang of this as the deferred network admin at my company so any assistance would be appreciated.

    We recently moved offices to a different location and thus did a static IP migration with AT&T in order to retain our LAN IP schema on our Netgate SG-8860 firewall gateway.

    Everything works fine as it did before with one exception:
    There are two remote employees that would get into our LAN via windows RDP to do work. This was done by the external client entering our WAN IP gateway - Lan IP block:Port number and then entering credentials to desktop it was arriving at in our LAN.

    Here is the port forward set up:


    Here is the WAN interface static info they used in RDP application:


    The problem is that AT&T shifted our LAN IP block from to

    So now the two remote clients cannot connect into our LAN from the previous WAN static info they have been using in their RDP application.

    What I think I must do is shift the IPv4 upstream gateway to and the IPv4 address to, my reasoning is that I would simply be increasing the last two number values accordingly to replicate what it was in form when they were able to connect with the old IP Lan block.

    Does this seem correct?

  • Netgate

    @virtuousmight said in IP Lan Block Migrated - Remote Access cannot get through Firewall Gateway:

    The problem is that AT&T shifted our LAN IP block from to

    Your LAN IP block? Looks like WAN to me. They should have specified the address you should use as a gateway. Probably But that would affect all internet traffic, not just a couple of port forwards. And those are not valid /29 networks. is inside The next highest /29 would be

    I don't care for destination any in a port forward. The destination address should be the address they are connecting to.

  • Thanks for the info....so I got information from ATT on our new WAN-LAN makeup and it shows this:


    And the WAN IP shows:


    So within the firewall you mentioned that this change would affect all internet traffic however the Ethernet LAN is operational still and I did not modify and configuration in the firewall after ATT did the changes to the WAN and LAN IP block.

    So should I modify the WAN interface settings in the firewall to match this information from ATT even though internet is operational with the exception of the 2 remote clients not being able to access the 2 desktops in our LAN?

  • I did a tracert to google dns and this is showing that the old IP gateway is still intact


    I am very confused.

  • @virtuousmight
    For your sake, please obfuscate your public IPs, especially as you appear to have RDP open from the Internet. Consider using a VPN or two-factor. Something like xx.yy.zz.96/29 is sufficient for the topic.

  • Netgate

    This post is deleted!

  • @dotdash Yep indeed, being hasty with this and publishing said data is not best practice so I can delete my posts correct ?

  • Netgate

    To me that looks like WAN should be configured like this:

    IPv4 Configuration Type: Static IPv4
    IPv6 Configuration Type: Static IPv6

    IPv4 Address: X.X.X.66 /30
    IPv4 Upstream Gateway: X.X.X.65

    IPv6 Address: 2001:1890:xxxx:xxxx::1143:6616 /64
    IPv6 Upstream Gateway: 2001:1890:xxxx:xxxx::ee43:6616

    X.X.X.96/29 looks like it is routed to you. A port forward on any of those addresses should work without Virtual IP addresses assigned.

    It looks like 2001:1890:xxxx:xxxx::/56 is also routed to you.

    The only thing I would change is asking for a /29 instead of a /30 and asking for a /48 instead of a /56. They should have no problems with either request and, IMHO, should not charge for either. If they ask you why you want the /29 on the interface, tell them you need 3 addresses for VRRP.

  • @derelict Will try that implementation. Thanks.

  • Netgate

    Did the WAN interface numberings change?

  • No. The WAN interface numberings in the firewall remained exactly the same as they were before this new circuit and IP migration was done. After I powered on the ATT managed router and the fiber circuit was activated I powered on the pfSense and the juniper switches and nothing was auto-reconfiged or manually reconfiged in the WAN interface at all. Even though ATT made these changes from their endpoint and segments.

  • Netgate

    OK if there's another router then you might have to put the /29 on the pfSense WAN port. That would be:

    IPv4 Configuration Type: Static IPv4
    IPv6 Configuration Type: None

    IPv4 Address: X.X.X.98 /30
    IPv4 Upstream Gateway: X.X.X.97

    You would have addresses 99-102 available for your port forwards, etc. You would need to add Virtual IP addresses so they ARP to the upstream router.

    I left off the IPv6 because there are several ways that can be done.

    I am really guessing here because I have no idea what the AT&T router brings to the table or what it does. I would put it in a closet if possible.

  • Okay I can work on that.

    I do plan to set up Open VPN with the wizard app in the firewall for these two clients to use as I have not done so before.

  • Netgate

    If AR is AT&T Router and CR is Customer Router, then the first scenario is correct, which is a much better configuration for you.

  • No other router, they just provided another lan IP block which I can use on a different port on the router. I am not entirely sure why. I think because we have had two (they get supplanted with each bandwidth upgrade and relocation) in the recent past and I wanted to conserve those IP schemes.

  • Netgate

    OK. A routed subnet is what you want. It is the proper way to do this.

    After I powered on the ATT managed router not sure what this is then.

  • @derelict Okay will have to research that thoroughly to ensure I do not make any errors.

    But I still do not understand why when I did the tracert the older lan IP gateway is still a route and that is not listed on the ATT info of the new circuit as you can see above.

  • Netgate

    You never know what is going to respond to traceroute. That router probably has a boatload of addresses on it and that is what it is choosing to source from in reply.