Static Configuration won't work - Ideas where to look?
-
Then try:
tracert 8.8.8.8
The first hop reported should be the IP address of your pfSense router, then the gateway of your ISP, then off to lots of hops in Internet-land.C:\Users\nate>tracert 8.8.8.8 Tracing route to google-public-dns-a.google.com [8.8.8.8] over a maximum of 30 hops: 1 2 ms <1 ms <1 ms pfsense.private [192.168.0.1] 2 * * * Request timed out. 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 ^C -
I can't believe that Comcast is putting that modem in true bridge mode for you.
When you set up your WAN for DHCP what address does it get?
-
I'm confused I did mean that I swapped Interfaces->WAN from DHCP to Static. But in my Services: DHCP Server the "Enable DHCP Service on WAN Interface" is unchecked. DHCP service is enabled on the LAN interface. Is DHCP supposed to be setup on the WAN interface?
That is correct. The pfSense DHCP Server is enabled on LAN, to give DHCP to the LAN clients (your PC etc). The WAN has a DHCP client only, which asks for DHCP network settings from a DHCP Server that your ISP provides.
Your LAN client PC network settings look fine - it goes to your pfSense for all network stuff - gateway, DHCP and DNS.
The traceroute goes to your pfSense then after that goes nowhere, presumably pfSense does not have a useful/valid default route.
The issue is presumably somewhere in getting useful DHCP settings on WAN from the ISP DHCP server.
What does Status:Interfaces show for WAN?
What does Diagnostics:Routes show for the default route? -
I can't believe that Comcast is putting that modem in true bridge mode for you.
When you set up your WAN for DHCP what address does it get?
I'm a little confused I have tested this setup with a 2 low grade routers. Both routers can access WAN through the assigned Static IP and pass the connection to internal LAN. It is definately something with the pf box. It is not passing the packets? to the LAN.
The SMC box by default is setup to apply 10.1.10.X addresses to hardware that is looking for DHCP. When I use DHCP on the pf box it receives a DHCP address of 10.1.10.X and a gateway address of 10.1.10.1. WAN works on anything given a DHCP address on the internal LAN from the pf box. It just won't pass when configured with a Static IP.
-
Comcast business does not allow static ips past the gateway device in the same manner as many other ISP's do. Ive fought with them over this in the past. The only true bridge modem they will allow is a Motorola 6000 series and they wont let you use it if you have a static IP address.
I believe in order to use your static IP your gonna need to leave the primary WAN as DHCP and use a VIP for the static. I wont use Comcast anywhere I need a static and have been lucky enough so far to have another solution available at those locations.
Did Comcast tech support provide you with instructions or any kind of direction?
If you set the WAN of any of your other routers up as DHCP they get a 10.x.x.x address, correct?
Unless Comcast has changed things in the last 6 mos. this is the way they do things.
-
The traceroute goes to your pfSense then after that goes nowhere, presumably pfSense does not have a useful/valid default route.
The issue is presumably somewhere in getting useful DHCP settings on WAN from the ISP DHCP server.
What does Status:Interfaces show for WAN?
What does Diagnostics:Routes show for the default route?
-
Okay just noticed this…
Gateway Status: Offline
-
http://www.dslreports.com/forum/r23503059-Business-Comcast-Business-gateway-bridge-mode-forwarding-iss
And there might be more here…
http://www.dslreports.com/nsearch?boardlist=141&cat=remark&advanced=1&141=1&p=10&o=r&q=SMC8014+static
-
This one caught my eye.
http://www.dslreports.com/forum/remark,25742306?hilite=smc8014+static
-
Comcast business does not allow static ips past the gateway device in the same manner as many other ISP's do. Ive fought with them over this in the past. The only true bridge modem they will allow is a Motorola 6000 series and they wont let you use it if you have a static IP address.
I believe in order to use your static IP your gonna need to leave the primary WAN as DHCP and use a VIP for the static. I wont use Comcast anywhere I need a static and have been lucky enough so far to have another solution available at those locations.
Did Comcast tech support provide you with instructions or any kind of direction?
If you set the WAN of any of your other routers up as DHCP they get a 10.x.x.x address, correct?
Unless Comcast has changed things in the last 6 mos. this is the way they do things.
This is a whole another discussion… and yes I can't stand the confusing setup of Comcast Routers for Biz Class. But you select two options and the router when faced with device presenting an external IP completely bypasses the router itself. As I stated the low grade routers work perfectly fine when configured with the exact static information that I am using on the pf box. Also yes this is how Comcast tells you to do this. I have a cPanel sever currently working on this router/connection setup the same way... Obviously different Static IP.
-
Gateway Status: Offline
I guess that the ISP Gateway does not respond to ping. So pfSense thinks that the WAN is down (no response from the Monitor IP).
Edit the Gateway settings and put in a Monitor IP of something real out in Internet-land that should always be up and respond to ping - I use 8.8.8.8 (Google DNS address). If that doesn't get you joy, then check the tickbox "Disable Gateway Monitoring" - pfSense will then always try to use the WAN interface, it won't appear "down".
If you don't have multi-WANs available on the pfSense box, then there is no real benefit in monitoring the only WAN Gateway and having it declared "down". -
Is your configured gateway (75.x.79.146) in the same subnet as the static IP you configured?
Where is the machine with this IP address? Is it your SMC modem?
If I recall correctly, some operating systems will talk directly to systems on the same LAN which aren't in the same subnet but FreeBSD takes a stricter view. So, for example, if your pfSense WAN interface has IP address 75.x.80.10/24 then pfSense won't talk directly to 75.x.79.156 because the two interfaces are in different subnets. I believe I have seen reports that Linux and/or Windows aren't so strict and that might explain why the two "low end" routers you mentioned are able to work in your configuration.
-
I am calling it quits… After a lengthy conversation with a Comcast tech I apparently using a hidden static IP that I am not supposed to have access to. I don't know why I have access with the low end routers and can't get it with pfSense. I don't know how I even originally found it. It would be nice to figure it out because it would save me the money of adding 3 extra unneeded Statics. But I will call Comcast tomorrow and add additional IP's. :-\
Thanks to all that attempted to help with my issue...
-
If you decide to try again I would try what phil.davis suggested above. Disable gateway monitoring or change the IP being monitored.
Also it doesn't look like you ran any ping tests from the pfSense console. This would determine if it was a routing problem or something upstream.
Steve
-
If you decide to try again I would try what phil.davis suggested above. Disable gateway monitoring or change the IP being monitored.
Also it doesn't look like you ran any ping tests from the pfSense console. This would determine if it was a routing problem or something upstream.
Steve
Well I'm still here… I got ticked off because I want to solve this. I have set the monitoring to watch 8.8.8.8. The status is now saying online but I still have no connection on my internal LAN devices.
I have run almost every test on the webconfigurator available. Nothing fails! It has been like this since the beginning. nslookup = good, ping LAN and WAN (google, ebay, and 8.8.8.8) = all good, tracert (google, ebay) = all working. Still my devices on internal LAN cannot resolve past the pfsense gateway address (192.168.0.1) as shown in the picture way earlier.
-
Ok so connectivity is good on pfsense WAN and LAN clients can connect the pfSense LAN side. In which case routing is not working or traffic is being blocked by the firewall. You can check the firewall logs to rule that out. Have you added/removed any firewall rules.
Make sure that Automatic Outbound NAT is enabled in Firewall: NAT: Outbound:
Steve
-
Ok so connectivity is good on pfsense WAN and LAN clients can connect the pfSense LAN side. In which case routing is not working or traffic is being blocked by the firewall. You can check the firewall logs to rule that out. Have you added/removed any firewall rules.
Make sure that Automatic Outbound NAT is enabled in Firewall: NAT: Outbound:
Steve
I checked that the Automatic Outbound NAT was enabled and it was. Also I did not change any of the rules from the preconfigured. The firewall log is filled with many blocks but I don't know how to interpret them.
-
Hmm, odd firewall hits. I assume the redacted destination IP is your WAN address? The odd thing is that it has 443 as the source port. :-\ Anyway they are all hits on WAN which the firewall is correctly blocking by default. If the firewall was preventing your clients send traffic out you would see hits on LAN. Unless you have changed the rules these will be allowed by the default 'lan to any' rule.
Ok so outbound NAT is set to auto (I'm not sure how to check that rules are actually being added here :-). The other thing that commonly breaks routing is a subnet conflict or subnet mask misconfiguration but yours look OK to me. :-
That in no way explains why it works when you have wan set to dhcp either.Steve
-
I think at this point I would run a packet capture on the WAN interface to check that ping requests are being correctly routed or replied to. However I'm not sure how well that will work in a VM.
Steve
-
Those IPs are ordinary places that people would use:
69.171.224.32 Facebook
23.48.50.110 Akamai Technologies - a web content provider that lots of pages reference
The packets are from port 443 - https - anyone starting a Facebook session would send stuff to Facebook on port 443, and should get an initial response back from port 443 which may soon hand off the comms for their new session to another port.
These packets from 443 should match a firewall state setup when the original user's packet went from LAN, NAT translation and out WAN. They should not be blocked, regardless of your firewall rules.
It seems that something weird is happening with the firewall states.
I am not familiar with all the options available when turning NAT off and on. In Firewall:NAT or System:Advanced:Firewall & NAT there might be setting that is not in its default state.
Enough talk, I'll let someone else thin kof what to look at next.
