Can't access certain web-sites
-
I don't think so.
The box that PFSense is running on is an old Dell GX260 workstation with a spare NIC added to it. After changing the MTU around so much I was really surprised that it didn't have any effect whatsoever. I mean, I've adjusted the MTU on windows boxes before with notable effect to get them talking across picky VPN tunnels. So it almost seemed as though the MTU changes I was making were just being disregarded (maybe my NIC didn't support the MTU change??)
I loaded a new box (old PowerEdge), added a couple of NICs, and got PFSense 1.2-RELEASE installed on that. After doing so, and swapping it into my test environment (on my "old" DSL WAN connection), I found I was able to get to duke-energy.com, as well as to the HTTPS extranet site I had problems with before. I also reset my NIC to full-duplex 10MB in the /conf/config.xml file and rebooted - everything is still working.
I'm not certain if I've found the problem. My path-forward now is to rebuild the config on my PowerEdge PFSense box, verify that my rules and everything are working, and swap it back into production. I'll update the post if I "break" this again at some point.
Any ideas on why the MTU changes were being ignored on the WAN interface?
-
I was just having the same problem, and tried the MTU thing etc. Turned out I had bad subnet settings, the way pfSense represents the subnet setting is a little confusing: Where "Static IP Configuration" in "interfaces>wan" there is a "/" and a number dropdown box next to your specified IP. These numbers represent your 255.255.255.0, etc, in a wierd format. 24 represents the standard 255.255.255.0, I had it at 1 and had problems, now I have it at 24 and I can access the sites I couldn't get to before (one of them being duke-energy.com).
-
That's not a wierd format. It's CIDR:
http://en.wikipedia.org/wiki/Classless_Inter-Domain_RoutingIt's how everyone should write their IP ranges.
(255.255.255.0 notation is outdated) -
Hmmm… I thought I had it figured out. But perhaps not. When I set my WAN interface at a.b.c.d/32 (I only have 1 static IP), I don't get any errors but I can't ping anything on the WAN interface. I changed it to a.b.c.d/30, (since I have no option for /31, and perhaps there are actually more allocated to me because the DSL bridge has an IP as well?), I have the same problem. If I set it to something else like... a.b.c.d/28, or a.b.c.d/27 (which I definitely don't have enough IPs for) I get this message...
There were error(s) loading the rules: pfctl: DIOCSETSTATUSIF - The line in question reads [ DIOCSETSTATUSIF]: ..
That being said, if set the WAN interface IP to a.b.c.d/14 - everything works. I can ping external IP addresses, and I don't seem to have any problems. I don't want to put this into production with a bad config on the WAN interface - but I don't understand why this works… any thoughts? Am I missing something here?
-
Everything in the above post is true, with the exception of the error message: "… DIOCSETSTATUSIF...". That has to do with me restoring my config file after removing an interface (captive portal) which no longer exists. Sorry for the confusion.
It remains true that I can only ping external web site when my WAN interface IP looks like this... a.b.c.d/14. If it's set to a.b.c.d/32, a.b.c.d/30, a.b.c.d/28 - nothing works.
Any ideas?
-
If I can ask, who is your ISP and what is the ip addressing scheme they gave for your WAN's subnet?
Did they specify to you an ip of say, a.b.c.d with a subnet of 255.255.25.0 or 255.255.255.240 or 255.255.255.248 (and so on)?
-
Fuse.net - and they specifed an IP address of, a.b.c.d and netmask of 255.255.255.248.
This means I should be specifying a.b.c.d/29 for my WAN interface, correct?
What I'm finding is that when set as a.b.c.d/29 I can't ping external devices. If the WAN interface is set to /14, /13, /12, etc. I'm able to ping external addresses. If I swap my production and test firewalls (production is non-pfsense), and reconfig the WAN interface on the non-pfsense box such that it's 255.255.255.248, I am now able to ping external addresses on the test WAN. Swapping back pfSense onto the test WAN at /29 breaks things again until I set the WAN inteface to /14.
-
OK, thanks for the updated info. Using a /29 would be the proper CIDR designation for a subnet mask of 255.255.255.248 as you mentioned using.
Silly question I'm going to ask: Have you rebooted/restarted your fuse.net modem/device?
One other item I've seen, if you set your subnet to /24 (255.255.255.0) does it help any? In some weird cases, I have seen it work when using that subnet mask.
Last item: When you say you cannot ping external ip's, do you mean those from your own ISP's side, or from other sites, such as 4.2.2.1 and etc.?
-
I did restart the ISP's bridge, and pfSense just to be certain.
I've tried most subnet settings from /29 on down, and it doesn't really start to work until around /15. Once I set it at /15 I'm able to ping external IP's that I try. By external IP's, I mean… I'm trying both my ISP's DNS server (216.68.4.10, etc.), as well as google.com.
Any chance that this might have something to do with my NIC? The WAN NIC on my pfSense box (Dell PowerEdge) is the on-board Intel NIC - but the behavior seems really odd.
-
your mask defines your subnet. your gateway should be in that subnet. as long as your gateway is within the subnet you should be able to ping the internet.
what I am trying to say is that all 3 settings need to work together.
-
I continued to have problems with my CIDR notation matching the subnet provided by my ISP for my DSL connection… since this didn't appear to make any sense at all, and everything else was working on the firewall, I reconfigured the WAN for my new internet connection (not the old DSL circuit), set my IP to the new IP/29 (as it should be), and put it into production. All is working as it should be now.
As was suggested by others here, and on #pfsense on IRC, this must have been something flaky with my ISP and/or DSL connection. Though I didn't get to the root cause, my DSL circuit is now off-line and everything is working as it should be on the new internet connection. Thanks to everyone for the assistance!
