Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Can't access certain web-sites

    Firewalling
    7
    16
    18.2k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      sb1
      last edited by

      I'm running PFSense 1.2-RELEASE, and am experiencing an odd problem accessing certain web-sites… one in particular is "http://www.duke-energy.com/", as well as a certain corporate intranet (HTTPS on 443).  Otherwise, I seem to be able to access most web sites without issue (google.com, yahoo.com, including HTTPS sites).  My firewall has 1 WAN port, and 1 LAN port.  No VLANs on the LAN side.  I'm using the PPTP server on PFSense, and have a few rules, and some NAT port-fowarding setup.

      As far as LAN rules, I have a few (i.e. allowing outbound SMTP from my SMTP server, and dropping outbound SMTP for everything else).  At the bottom I have the following - which should allow outbound traffic form my LAN:

      "protocol *, Source LAN, port *, Destination *, port *, gateway *

      I have no rules associated with http://www.duke-energy.com/ (192.234.122.137).  On my WAN rules, I have a few NATing stuff like ports 80, 443, 21, etc. to the appropriate boxes.

      I've done some packet captures, and have used fiddler to watch what happens... essentially the client on the LAN makes a require of 192.234.122.137:80, but never gets a response.  If I point my LAN client at a different gateway (and different internet connection), I do not experience any problems getting to www.duke-engergy.com.

      1 Reply Last reply Reply Quote 0
      • R
        razor2000
        last edited by

        It could be the routes your ISP is currently using to get to the www.duke-energy.com website.  I'd suggest opening a command prompt and doing a tracert to the 192.234.122.137 ip and see where the packets stop off at.  I have seen this happen before where either your modem's or ISP's modem routing table goes whack (temporarily) and causes this to happen.  If rebooting your modem doesn't help, contact your ISP and see what can happen (if possible).

        Hope this helps…  Good luck!

        1 Reply Last reply Reply Quote 0
        • P
          Perry
          last edited by

          Your mtu at interfaces>wan is probably too high. Try to set it to 1400 and retest. If these sites work then try to go up with the mtu again until it breaks and then one step back. Other option is to use pings with fixed packetsize and no fragment flag to find out your max mtu. Search google for how this is done for the OS of your chioce (in case this is a windows box rin ping /? to see these options).

          http://www.dslreports.com/faq/695

          /Perry
          doc.pfsense.org

          1 Reply Last reply Reply Quote 0
          • S
            sb1
            last edited by

            Razor200 - I actually moved PFSense from my new internet connection (where I'm having problems), to my old internet connection (where I wasn't having problems).  In other words, I swapped the firewalls.  As soon as I did this, the problem was resolved on the new internet connection (now using the old non-Pfsense firewall), and suddenly appeared on my old internet connection (now using PFSense).  Next, I tried running a traceroute to 192.234.122.137 and it's still failing just after the first hop (.251 - PFsense).

            Perry - I adjusted my MTU size in PFSense (Interfaces>WAN>General configuration, MTU) as low as 600 and as high as 1600 (rebooting PFSense after each modification).  So far, I'm still not able to access duke-energy.com, and based on some user comments, users at one specific remote site are not able to acceess any resources (SMTP, Web, etc.) at my location.  Though everyone else is able to access our site without issue.

            Is there another MTU change I need to be making somewhere else?

            1 Reply Last reply Reply Quote 0
            • H
              hoba
              last edited by

              Wrong subnet settings at interfaces>wan?

              1 Reply Last reply Reply Quote 0
              • S
                sb1
                last edited by

                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?

                1 Reply Last reply Reply Quote 0
                • K
                  kcghost
                  last edited by

                  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).

                  1 Reply Last reply Reply Quote 0
                  • GruensFroeschliG
                    GruensFroeschli
                    last edited by

                    That's not a wierd format. It's CIDR:
                    http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing

                    It's how everyone should write their IP ranges.
                    (255.255.255.0 notation is outdated)

                    We do what we must, because we can.

                    Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

                    1 Reply Last reply Reply Quote 0
                    • S
                      sb1
                      last edited by

                      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?

                      1 Reply Last reply Reply Quote 0
                      • S
                        sb1
                        last edited by

                        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?

                        1 Reply Last reply Reply Quote 0
                        • R
                          razor2000
                          last edited by

                          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)?

                          1 Reply Last reply Reply Quote 0
                          • S
                            sb1
                            last edited by

                            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.

                            1 Reply Last reply Reply Quote 0
                            • R
                              razor2000
                              last edited by

                              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.?

                              1 Reply Last reply Reply Quote 0
                              • S
                                sb1
                                last edited by

                                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.

                                1 Reply Last reply Reply Quote 0
                                • S
                                  sai
                                  last edited by

                                  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.

                                  1 Reply Last reply Reply Quote 0
                                  • S
                                    sb1
                                    last edited by

                                    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!

                                    1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post
                                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.