No internet connectivity on WAN with valid public IP

  • Hello everyone,

    this is my first post to this forum after frustrating hours and days spent with pfSense and researching the internet (including this forum) without finding anything to help with my - probably very basic - issues. Please be gentle if I have overseen already available topics…

    I made a fresh install of pfSense
        2.1.5-RELEASE (i386)
        built on Mon Aug 25 07:44:26 EDT 2014
        FreeBSD 8.3-RELEASE-p16
    on some simple intel-hardware with two NICs, one onboard and one 3Com, both 100MBit.

    Installation went fine, I was able to assign the NICs to WAN and LAN respectively including static IPs (on both; no DHCP-server or -client settings on either!):

    • the LAN-NIC was assigned a plain private static IPv4 172.24.x.x/16 and connected to our LAN-subnet

    • the WAN-NIC was assigned a valid available static IPv4 /28 from our pool of IPs and connected directly to our internet facing subnet; default gateway is also configured correctly

    Now I can access the web interface through the LAN-IP from our LAN fine and finished the basic initial configuration of pfSense.

    Before continuing I thought I would check basic connectivity using the pfSense Shell. Obviously the LAN-connection was working (ping etc.) but I couldn't reach anything through the WAN-interface outbound from the pfSense Shell. Now I am not talking about routing, NAT or anything sophisticated I just couldn't even ping an existing IP in our external subnet directly connected to the WAN-interface, let alone anything in the internet (both from the pfSense Shell or web-interface). Needless to say as a side-effect I cannot check for updates through the web-interface ("Unable to check for updates").

    I double checked my IP-configuration on the WAN-interface, even repeated the complete installation with the same result.

    Researching various forums I read about DNS-problems that do not apply to my specific problem here, though, because I haven't even got to name resolution yet: I'm just trying to ping an IPv4-address from a linux console… I even tried adding a firewall PASS-rule to allow outbound traffic on the WAN-interface... no change. To make sure my hardware was ok I even switched the WAN/LAN-assignment of the NICs. Same result: LAN works, WAN doesn't.

    In the past I have configured and maintained several firewalls and proxy servers using Linux IPTABLES, Windows ISA/TMS etc. and I am very aware of our - not too complicated - subnet-topology: I thought - before I start anything high-level - I would just get both NICs communicating on their respective subnets just as all of our other servers directly connected to our ISPs-router's subnet do.

    Now I am, of course, aware that inbound traffic on the WAN-interface is probably initially blocked, which is fine; I am now only talking about outbound traffic...

    Obviously I am missing something. Can anyone help?


  • Your WAN IP is public?

  • Thank you for your reply.

    Yes, the WAN IP is public and available; we have a public IP-range from our ISP and working ISA-proxys, other Linux-firewalls and web- and mail-servers in this subnet.

    Both the WAN and LAN interfaces are reported as "online" on the web-dashboard; the gateway is shown as offline (since there is not network connectivity that is not surprising).


  • Netgate Administrator

    If the LAN is shown as 'online' does that mean you have put a gateway on it?
    If so remove it. Then go to System: Routing: Gateways: in the webgui and ensure the WAN is set as default.

    Another common issue is that FreeBSD sticks rigidly to the specs such that the WAN gateway must be in the WAN subnet. Both Linux and Windows have a more flexible approach.

    When you try to ping something on the WAN side what is the error given?


  • Going to need a gateway on the WAN to get internet.

  • Hello,

    Thank you for your replies.

    The LAN has no gateway configured; the WAN has the correct gateway IP configured (which is actively being used by several other proxies in this subnet) and it is the default gateway in pfSense.

    The gateway is in the WAN subnet.

    Pinging the gateway (or any other IPs that can successfully be pinged from any other host in the WAN subnet) from pfSense results in 100% packet loss; the error message is "ping: sendto: Host is down".

    Does any of this help?


  • LAYER 8 Netgate

    Screenshot of WAN interface, LAN interface, WAN firewall rules, and LAN firewall rules, and NAT if you changed it to manual outbound.

    Are you pinging from the pfSense command line, the tool in Diagnostics, or a host on the LAN?

    A rule like this will permit outside to ping your WAN.  You can set source to "WAN net" if you want to limit it to just your WAN subnet.  Note that this has no effect on pinging out - but it might help you with the troubleshooting process.

    ![Screen Shot 2014-09-21 at 12.39.19 PM.png](/public/imported_attachments/1/Screen Shot 2014-09-21 at 12.39.19 PM.png)
    ![Screen Shot 2014-09-21 at 12.39.19 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-09-21 at 12.39.19 PM.png_thumb)

  • Netgate Administrator

    That ping response tells me that the pfSense box has a route to the hosts (or thinks it does) and can talk to its NIC hardware. Check the firewall logs for blocked ping responses. There shouldn't be any because it's an existing state.
    This means that either the ping target isn't responding, maybe it has a software firewall or no route back to the pfSense box, or that it's responses are going to the wrong place, it has bad routing info or a bad subnet mask perhaps. Maybe the ping never reached the target, perhaps it's outside the subnet.
    When you said the interface are reported as 'online' did you mean UP? (green arrow). The gateway reported offline is not surprising as you say. The apinger process used to monitor it uses pings. Check the Status: Interfaces: page for errors/collisions on the WAN. Since you are using static IPs it's harder to tell if any connectivity is present at all. What does 'ifconfig' report as the media status for the WAN?


  • @Derelict: I have changed no settings at all yet (after configuring the interfaces), it is an absolutely fresh install: WAN and LAN interfaces are both reported as "up". All ping-Tests are either done from the pfSense shell at the box itself or from the tool in diagnostics; the results are the same. I haven't tried pinging the WAN from outside yet because I expected it to be "locked-down" initially, that's why I started with my outbound tests.

    @stephenw10: The media status for both interfaces in ifconfig is "active" and it recognizes when I pull the plug; both LAN and WAN are UP and have a green arrow. The WAN interface is directly connected to the switch with all other outside hosts that can be reached. E.g. there is a Windows Server on that subnet that replies to ping from any other host; my pfSense cannot reach it… No errors/collisions reported.


  • LAYER 8 Netgate

    Anything in Diagnostics->ARP Table for the WAN interface that's interesting?

    This stuff just works.  You have something misconfigured.  Is the pfSense switchport in the right VLAN?

  • I'd probably have to see most of your configuration and it looks like you are keeping it secret.

    I can't tell more with all the black and without seeing probably most of your config.

    What I saw didn't seem to have obvious problems, but I saw very little.

  • Netgate Administrator

    Is the WAN side switch layer 2 or 3? It looks like you have some basic connectivity issue here that would be obvious if you were using dhcp on the WAN but it's being hidden by the static addressing. As a test try setting the wan to dhcp and connecting it to some dhcp server.


  • Sorry for the delayed reply. After reading this:


    This stuff just works.

    (which were my thoughts precisely!) we exchanged cables, changed the patching, and did tons of other stuff… in the end we had the network guys check the built-in cabling in the room we were working in: there were only four network sockets, two (!) of which were faulty...! A week earlier they said they had tested and everything had been fine!?

    So: thanks everyone for your help and your time and sorry about the waste of time on your parts.


Log in to reply