Possible NAT issues with private/RFC1918 IPs on WAN interface.

  • Hi All

    So I have a bit of a weird situation. I have a pfSense 2.3.1 instance whereby the WAN interface is on a private / non-routable / RFC1918 IP range (in this case, that is then hooked into another router that has internet facing IPs (long story as to why, not really relevant here) and I'm getting weird issues with internet access from the router itself.

    I can connect a PC to the LAN side and get internet perfectly, I can ping google.com from the console and it resolves DNS and gets a reply, I can telnet to port 80 on google.com and get a connection and a response back, but when I go to the webUI and try and either check for updates or install a package it fails and cannot find internet.

    I tried changing to manual NAT and telling it to NOT NAT when the source IP is the WAN range and no luck.

    I've then thrown the WAN side onto a public IP hanging off the same router (I had a /29 public range I could re purpose temporarily) and it all works perfectly.

    This isn't the first issue I've had with the 2.3/2.3.1 builds and private IPs on the WAN side (I have another post whereby I had private IPs on WAN with a public CARP address and heaps of issues including PHP/webUI hanging and needing option 16 run every few minutes to get things working, but never yeilded any replies). My gut feeling points to NAT issues.

    I was just wondering if anyone having issues with NATting in recent releases, specifically with private IPs on WAN side?

  • No issues. What specifically are you trying to do? Generally the source IP of the WAN range will never hit that system to even process NAT.

    The issue you noted with the GUI dying with no Internet access was fixed in 2.3.1.

  • All I was trying to do was install a package (OpenBGPD) which kept failing, and the update check on the dashboard kept failing after long waits, yet i could still ping outbound sourcing from both LAN and WAN IPs, had internet access on clients hanging off the LAN interface, traceroutes looked exactly as expected and everything else looked perfect.
    I originally thought it was something weird in 2.3.1 so I reinstalled with 2.3 and still had the issue.

    Interesting to hear the GUI dying has been fixed, I will give it a go with my original setup (using internal IPs for the interfaces and a single public CARP IP) and see if it's any better.


  • Sounds like you had everything right. The only other thing I can think of is if you had bunk IPv6 configured, so the system thought it was v6-connected but isn't. It'd prefer v6 in that case, and currently doesn't fall back to v4. Can set v4 as preferred under System>Advanced, Misc if that's the case.

Log in to reply