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

    Static Configuration won't work - Ideas where to look?

    Problems Installing or Upgrading pfSense Software
    6
    36
    9.9k
    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.
    • chpalmerC
      chpalmer
      last edited by

      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

      Triggering snowflakes one by one..
      Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

      1 Reply Last reply Reply Quote 0
      • chpalmerC
        chpalmer
        last edited by

        This one caught my eye.

        http://www.dslreports.com/forum/remark,25742306?hilite=smc8014+static

        Triggering snowflakes one by one..
        Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

        1 Reply Last reply Reply Quote 0
        • N
          natelabo
          last edited by

          @chpalmer:

          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.

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

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

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • W
              wallabybob
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • N
                natelabo
                last edited by

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

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  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

                  1 Reply Last reply Reply Quote 0
                  • N
                    natelabo
                    last edited by

                    @stephenw10:

                    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.

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      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

                      1 Reply Last reply Reply Quote 0
                      • N
                        natelabo
                        last edited by

                        @stephenw10:

                        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.

                        DiagnosticsFirewallLogs.png
                        DiagnosticsFirewallLogs.png_thumb

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          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

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            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

                            1 Reply Last reply Reply Quote 0
                            • P
                              phil.davis
                              last edited by

                              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.

                              As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                              If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                              1 Reply Last reply Reply Quote 0
                              • stephenw10S
                                stephenw10 Netgate Administrator
                                last edited by

                                Hmm, stateful firewall broken. Had not considered that!
                                I have no idea how one might break that or how switching from a dhcp assigned WAN to static might do it.  :-\

                                Steve

                                1 Reply Last reply Reply Quote 0
                                • N
                                  natelabo
                                  last edited by

                                  I went into NAT configuration and moved from auto to manual. It created some rules I deleted those and then moved back to auto from manual. It seems to have fixed the blocks being reported in the firewall. Still no connectivity.

                                  I did a packet capture on the wan interface… I then attempted to browse to google.com from a local device. Packets go through but I once again don't know how to interpret it.

                                  OK scratch that I am still getting blocked...

                                  1 Reply Last reply Reply Quote 0
                                  • N
                                    natelabo
                                    last edited by

                                    Could someone take a look at these logs from the packet capture (I picked an interface and then on a local device attempted to go to google.com):

                                    
WAN Interface

16:57:41.101959 IP 75.144.79.144.13192 > 74.125.225.78.443: tcp 0
16:57:41.108078 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 23150, length 44
16:57:41.125294 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:41.144520 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 23150, length 44
16:57:41.455705 IP 10.0.0.0 > 224.0.0.1: igmp
16:57:41.580017 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:41.664690 IP 75.144.79.144.3756 > 74.125.225.78.443: tcp 0
16:57:41.685577 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:42.039584 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:42.118017 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 23406, length 44
16:57:42.149849 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 23406, length 44
16:57:42.180303 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:42.638573 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:43.128024 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 23662, length 44
16:57:43.161202 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 23662, length 44
16:57:43.380435 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:43.838306 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:43.995745 IP 75.144.79.144.39147 > 74.125.225.70.443: tcp 0
16:57:44.017177 IP 74.125.225.70.443 > 75.144.79.144.39147: tcp 0
16:57:44.098672 IP 75.144.79.144.13192 > 74.125.225.78.443: tcp 0
16:57:44.120593 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:44.137956 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 23918, length 44
16:57:44.170392 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 23918, length 44
16:57:44.383626 IP 74.125.225.70.443 > 75.144.79.144.39147: tcp 0
16:57:44.664647 IP 75.144.79.144.3756 > 74.125.225.78.443: tcp 0
16:57:44.685868 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:44.699328 IP 75.144.79.144.36950 > 74.125.225.68.443: tcp 0
16:57:44.722696 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
16:57:44.728673 IP 75.144.79.144.4217 > 74.125.225.70.443: tcp 0
16:57:44.749215 IP 74.125.225.70.443 > 75.144.79.144.4217: tcp 0
16:57:44.966891 IP 75.144.79.144.32177 > 74.125.225.68.443: tcp 0
16:57:44.988638 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
16:57:45.147931 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 24174, length 44
16:57:45.180448 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 24174, length 44
16:57:45.182179 IP 74.125.225.70.443 > 75.144.79.144.4217: tcp 0
16:57:45.184711 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
16:57:45.410414 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
16:57:45.781167 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:45.783714 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
16:57:46.010282 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
16:57:46.157899 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 24430, length 44
16:57:46.190517 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 24430, length 44
16:57:46.237759 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:46.691304 IP 75.144.79.144.38380 > 173.194.68.125.443: tcp 0
16:57:46.734180 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
16:57:46.941749 IP 75.144.79.144.33876 > 173.194.68.125.443: tcp 0
16:57:46.982674 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
16:57:46.983864 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
16:57:47.128039 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
16:57:47.167852 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 24686, length 44
16:57:47.202763 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 24686, length 44
16:57:47.210433 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
16:57:47.282514 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
16:57:47.700973 IP 75.144.79.144.36950 > 74.125.225.68.443: tcp 0
16:57:47.723263 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
16:57:47.729600 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
16:57:47.882395 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
16:57:47.961005 IP 75.144.79.144.32177 > 74.125.225.68.443: tcp 0
16:57:47.982889 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
16:57:48.116661 IP 75.144.79.144.26289 > 75.75.76.76.53: UDP, length 28
16:57:48.116694 IP 75.144.79.144.26289 > 8.8.8.8.53: UDP, length 28
16:57:48.116721 IP 75.144.79.144.26289 > 8.8.4.4.53: UDP, length 28
16:57:48.116746 IP 75.144.79.144.26289 > 75.75.75.75.53: UDP, length 28
16:57:48.132922 IP 75.75.76.76.53 > 75.144.79.144.26289: UDP, length 204
16:57:48.136766 IP 75.144.79.144.17085 > 74.125.225.130.80: tcp 0
16:57:48.153083 IP 8.8.4.4.53 > 75.144.79.144.26289: UDP, length 204
16:57:48.153130 IP 8.8.8.8.53 > 75.144.79.144.26289: UDP, length 204
16:57:48.164292 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
16:57:48.167216 IP 75.75.75.75.53 > 75.144.79.144.26289: UDP, length 204
16:57:48.177827 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 24942, length 44
16:57:48.209769 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 24942, length 44
16:57:48.456216 IP 10.0.0.0 > 224.0.0.1: igmp
16:57:48.549640 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
16:57:48.930197 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
16:57:49.084248 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
16:57:49.149509 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
16:57:49.187781 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 25198, length 44
16:57:49.221121 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 25198, length 44
16:57:49.385864 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
16:57:49.611598 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
16:57:49.695145 IP 75.144.79.144.38380 > 173.194.68.125.443: tcp 0
16:57:49.741328 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
16:57:49.945167 IP 75.144.79.144.33876 > 173.194.68.125.443: tcp 0
16:57:49.987475 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
16:57:50.108172 IP 75.144.79.144.13192 > 74.125.225.78.443: tcp 0
16:57:50.135905 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:50.197745 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 25454, length 44
16:57:50.229454 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 25454, length 44
16:57:50.351753 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
16:57:50.583027 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
16:57:50.668264 IP 75.144.79.144.3756 > 74.125.225.78.443: tcp 0
16:57:50.691144 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:51.040863 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
16:57:51.139318 IP 75.144.79.144.17085 > 74.125.225.130.80: tcp 0
16:57:51.160980 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
16:57:51.207707 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 25710, length 44
16:57:51.242954 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 25710, length 44
16:57:51.332369 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
16:57:51.484095 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
16:57:52.217676 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 25966, length 44

------------------------------------------------------------------
LAN Interface

16:58:53.524036 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.664922 IP 192.168.0.200.64336 > 74.125.225.134.443: tcp 0
16:58:53.723976 IP 192.168.0.200.64343 > 192.168.0.99.80: tcp 0
16:58:53.724061 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.724063 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.724594 IP 192.168.0.200.64343 > 192.168.0.99.80: tcp 0
16:58:53.724628 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.724630 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.724632 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.724634 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.725108 IP 192.168.0.200.64343 > 192.168.0.99.80: tcp 0
16:58:53.725146 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.725148 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.725150 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
16:58:53.725152 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 495
16:58:53.725640 IP 192.168.0.200.64343 > 192.168.0.99.80: tcp 0
16:58:53.733891 IP 192.168.0.200.64337 > 74.125.142.125.443: tcp 0
16:58:53.983895 IP 192.168.0.200.64338 > 74.125.142.125.443: tcp 0
16:58:54.229110 IP 192.168.0.200.50855 > 192.168.0.99.53: UDP, length 33
16:58:54.246739 IP 192.168.0.99.53 > 192.168.0.200.50855: UDP, length 49
16:58:54.455911 IP 10.0.0.0 > 224.0.0.1: igmp
16:58:54.907004 IP 192.168.0.200.64339 > 74.125.225.32.443: tcp 0
16:58:55.137092 IP 192.168.0.200.64340 > 74.125.225.32.443: tcp 0
16:58:56.767269 IP 192.168.0.200.64341 > 74.125.225.131.443: tcp 0
16:58:56.987238 IP 192.168.0.200.64342 > 74.125.225.131.443: tcp 0
16:58:57.843056 IP 192.168.0.200.64350 > 74.125.225.130.80: tcp 0
16:58:58.612801 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
16:58:59.014081 IP 192.168.0.200.64351 > 74.125.225.134.443: tcp 0
16:58:59.363421 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
16:58:59.773368 IP 192.168.0.200.64352 > 74.125.225.134.443: tcp 0
16:59:00.113507 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
16:59:00.843563 IP 192.168.0.200.64350 > 74.125.225.130.80: tcp 0
16:59:00.910479 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
16:59:01.455647 IP 10.0.0.0 > 224.0.0.1: igmp
16:59:01.660603 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
16:59:02.013532 IP 192.168.0.200.64351 > 74.125.225.134.443: tcp 0
16:59:02.410700 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
16:59:02.773546 IP 192.168.0.200.64352 > 74.125.225.134.443: tcp 0
16:59:03.163869 IP 192.168.0.200.52811 > 192.168.0.99.53: UDP, length 37
16:59:03.182386 IP 192.168.0.99.53 > 192.168.0.200.52811: UDP, length 106
16:59:03.187650 IP 192.168.0.200.64354 > 207.46.206.137.80: tcp 0

                                    I don't care about hiding the external IP anymore…. I'm not going to be using it for long.

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