Cannot connect to Internet when using Static IP on WAN side
-
I am testing a MetroEthernet connection using Untangle and pfSense (1.2.3-Release) in series.
When the Untangle service faces the internet, the clientPC can access the internet:
Internet->–<184.x.x.x:Untangle:192.168.4.1>--<192.168.4.50:pfSense:192.168.5.1>--<192.168.5.50:clientPC:
In the case above, I have successfully assigned a non-internet-routable IP via DHCP and via static assignment on the WAN interface of the pfSense box and had internet access.
When I remove the Untangle box from the setup, and reconfigure the WAN interface of the pfSense box with the routable IP and gateway addresses, I can no longer connect to the internet:
Internet->--<184.x.x.x:pfSense:192.168.5.1>--<192.168.5.50:clientPC:
In the non-working scenario, I can ping the 184.x.x.x address from the pfsense web interface but I cannot ping anything on the internet (i.e. ping 8.8.8.8 [google]). I have tried rebooting after changing the configuration and also resetting pfSense to a factory fresh condition but that did not work. The ping test eliminates the clientPC as the problem, so I am left thinking I have done something wrong with the pfsense configuration. Thoughts?
-
i'm a newb, but i think i understand the problem, it's very odd if you can't even use pfsense in the default sense as a initial setup router…. have you tried plugging a client PC directly into the internet connection to see what happens?
-
. . . I am left thinking I have done something wrong with the pfsense configuration. Thoughts?
On the pfSense box:
-
What default gateway address did you use?
-
What is the WAN interface IP address and subnet mask?
-
Does pfSense have a default route (shell command # netstat -rn)
-
-
Hi wallabybob,
Thanks for responding.
On the pfSense box:
-
What default gateway address did you use?
-
What is the WAN interface IP address and subnet mask?
-
Does pfSense have a default route (shell command # netstat -rn)
Gateway on WAN: 184.12.11.1
Default Gateway on LAN: 192.168.5.1
WAN interface IP and subnetmask: 184.12.11.1/29
Routing information is below:$ netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 184.12.11.1 UGS 0 4 vr1 127.0.0.1 127.0.0.1 UH 0 0 lo0 184.12.11.0/29 link#2 UC 0 0 vr1 184.12.11.1 00:0d:b9:1f:bf:c5 UHLW 2 0 lo0 192.168.5.0/24 link#1 UC 0 0 vr0 192.168.5.245 00:1e:68:2a:39:59 UHLW 1 725 vr0 1199 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%vr0/64 link#1 UC vr0 fe80::20d:b9ff:fe1f:bfc4%vr0 00:0d:b9:1f:bf:c4 UHL lo0 fe80::%vr1/64 link#2 UC vr1 fe80::20d:b9ff:fe1f:bfc5%vr1 00:0d:b9:1f:bf:c5 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#6 UHL lo0 ff01:1::/32 link#1 UC vr0 ff01:2::/32 link#2 UC vr1 ff01:6::/32 ::1 UC lo0 ff02::%vr0/32 link#1 UC vr0 ff02::%vr1/32 link#2 UC vr1 ff02::%lo0/32 ::1 UC lo0
Another Observation: When I do an ipconfig on my machine, I notice that two default gateways are listed: 0.0.0.0 and 192.168.5.1. I'm not sure where the 0.0.0.0 is coming from.
-
-
…. have you tried plugging a client PC directly into the internet connection to see what happens?
Hi krazyderek,
Thanks for your suggestion. My PC can successfully connect to the internet when plugged directly into the MetroEthernet router.
-Scott
-
My observation regarding 2nd gateway address of 0.0.0.0 on my client PC is a red herring (unrelated). I have eliminated that issue (Vista ::)).
-
At the very least you have a routing problem. Your default route is to 184.12.11.1 which is the IP address of your WAN interface. Your WAN gateway should be an IP address on the same subnet as your WAN interface (but not the same IP address as your WAN interface).
Consider how a packet should get to 8.8.8.8. There is no information to get a packet past your WAN interface.
PERHAPS your ISP has allocated you an address block 184.12.11.0/29 with a gateway of 184.12.11.1. In that case it is probably expected that your pfSense gateway would have a WAN interface IP address of 184.12.11.2 or 184.12.11.3 or … or 184.12.11.14
-
Thanks wallabybob for calling out the routing issue. Though your suggestion didn't immediately solve my problem, it got me to thinking and I decided to call my ISP for additional information on my IP address block. It turns out that I needed to use a different IP range on the WAN side of the interface. Case closed.