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

    pfsense not using GoDaddy's domain forward, only for internal users

    Scheduled Pinned Locked Moved General pfSense Questions
    20 Posts 3 Posters 1.2k Views
    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
      scottys
      last edited by

      Side note: I have set up tests that have it redirect to google.com and other sites besides ours. The forwarding on those do not work either

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

        So it fails accessing both order.castrolroadside.ca and nsdmc.com/something from an internal client?

        When you ran the packet capture which IP was it trying to reach? On the internal interface?

        A 301 redirect is an http function rather than DNS. If it just resolved correctly with DNS I doubt this would be an issue.
        The initial connection to 184.168.131.241 will not be caught by NAT reflection since that's obviously not forwarded locally. I would expect the redirected connection to your WAN to be caught though.

        Steve

        S 1 Reply Last reply Reply Quote 0
        • S
          scottys @stephenw10
          last edited by

          @stephenw10 said in pfsense not using GoDaddy's domain forward, only for internal users:

          So it fails accessing both order.castrolroadside.ca and nsdmc.com/something from an internal client?

          No. order.castrolroadside.ca fails from an internal user but works normally outside of pfsense. nsdmc.com/something is accessible from both internal and external users

          When you ran the packet capture which IP was it trying to reach? On the internal interface?

          It hit the internal interface (pfsense) and going to 184.168.131.241, but nothing seems to be returned while following the packet trail.

          A 301 redirect is an http function rather than DNS. If it just resolved correctly with DNS I doubt this would be an issue.

          I understand. Just trying to explain the setup we have as that 301 redirect is setup in the same place where the DNS is for that domain.

          The initial connection to 184.168.131.241 will not be caught by NAT replaction since that's obviously not forwarded locally. I would expect the redirected connection to your WAN to be caught though.

          Caught how? Could pfsense be "stripping" the SNI or other parts that would say "I am trying to go to order.castrolroadside.ca" and not "I am trying to go to 184.168.131.241"
          The latter seems like what is going on, since that is the same IP for GoDaddy redirects in their DNS zone

          Example:
          nsd-test.com does not work for me, but if you go there it should redirect you to google

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

            Ok, not a NAT reflection issue if you can't see redirects to an external site either.

            Is it even succeeding with the connection to 184.168.131.241?

            Probably time for a packet capture of the connection or maybe check the browser console.

            Steve

            S 1 Reply Last reply Reply Quote 0
            • S
              scottys @stephenw10
              last edited by

              @stephenw10 said in pfsense not using GoDaddy's domain forward, only for internal users:

              Is it even succeeding with the connection to 184.168.131.241?

              No, it is not responding to pings where when I ping the IP from my phone it works. This would mean pfsense is blocking it, but I have checked everyplace it could be blocked (pfBlockerNG, Snort, Aliases, etc) and the IP not in there.

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

                Or it could be mis-routed somehow...

                S 1 Reply Last reply Reply Quote 0
                • S
                  scottys @stephenw10
                  last edited by

                  @stephenw10 said in pfsense not using GoDaddy's domain forward, only for internal users:

                  Or it could be mis-routed somehow...

                  I am checking every rule that is in place and it doesn't make sense.

                  I think it is a godaddy issue. I just tested on one of my personal domains using a different DNS provider (1and1) and it redirected me just fine...

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

                    Confirmed that it is something in the pfsense. Tested from my homelab, which uses pfsense, and all the redirects work perfectly. I am at a loss for word with all the frustration this is causing

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

                      Ok, run a packet capture for that IP on WAN, is it even leaving?

                      Mystery disappearing packets... check IPSec tunnels.

                      Traffic that is blocked and not logged, check pfBlocker, Snort and Suricata if you have any of those installed.

                      Steve

                      S 2 Replies Last reply Reply Quote 0
                      • S
                        scottys @stephenw10
                        last edited by

                        @stephenw10 said in pfsense not using GoDaddy's domain forward, only for internal users:

                        Ok, run a packet capture for that IP on WAN, is it even leaving?

                        Mystery disappearing packets... check IPSec tunnels.

                        Traffic that is blocked and not logged, check pfBlocker, Snort and Suricata if you have any of those installed.

                        Steve

                        The packet capture shows it hitting pfsense main gateway to go out, but I dont think it is leaving. No IPSec, and the IP or my workstation IP does not show up in pfBlockerNG, snort, and custom aliases (as we have a rule for specific hosts/networks to block.)

                        It literally just disappears. I'll post a packet capture tomorrow when I get there

                        1 Reply Last reply Reply Quote 0
                        • S
                          scottys @stephenw10
                          last edited by

                          @stephenw10 said in pfsense not using GoDaddy's domain forward, only for internal users:

                          Ok, run a packet capture for that IP on WAN, is it even leaving?

                          Mystery disappearing packets... check IPSec tunnels.

                          Traffic that is blocked and not logged, check pfBlocker, Snort and Suricata if you have any of those installed.

                          Steve

                          Packet Capture on backup pfsense (that works)

                          11:12:48.920644 d8:9e:f3:12:77:6d > 00:1b:21:8b:15:80, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 60463, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5329 > 184.168.131.241.80: Flags [S], cksum 0xde49 (correct), seq 2187747910, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:12:48.920646 d8:9e:f3:12:77:6d > 00:1b:21:8b:15:80, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 60464, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5330 > 184.168.131.241.80: Flags [S], cksum 0x2732 (correct), seq 509181290, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:12:49.920854 d8:9e:f3:12:77:6d > 00:1b:21:8b:15:80, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 60465, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5330 > 184.168.131.241.80: Flags [S], cksum 0x2732 (correct), seq 509181290, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:12:49.921617 d8:9e:f3:12:77:6d > 00:1b:21:8b:15:80, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 60466, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5329 > 184.168.131.241.80: Flags [S], cksum 0xde49 (correct), seq 2187747910, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:12:50.004757 00:1b:21:8b:15:80 > d8:9e:f3:12:77:6d, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 52, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    184.168.131.241.80 > 90.0.0.95.5329: Flags [S.], cksum 0xf48b (correct), seq 1184051546, ack 2187747911, win 29200, options [mss 1380,nop,nop,sackOK,nop,wscale 7], length 0
11:12:50.005159 d8:9e:f3:12:77:6d > 00:1b:21:8b:15:80, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 60467, offset 0, flags [DF], proto TCP (6), length 40)
    90.0.0.95.5329 > 184.168.131.241.80: Flags [.], cksum 0xa31e (correct), seq 1, ack 1, win 1024, length 0
11:12:50.005824 d8:9e:f3:12:77:6d > 00:1b:21:8b:15:80, ethertype IPv4 (0x0800), length 345: (tos 0x0, ttl 128, id 60468, offset 0, flags [DF], proto TCP (6), length 331)
    90.0.0.95.5329 > 184.168.131.241.80: Flags [P.], cksum 0x3446 (correct), seq 1:292, ack 1, win 1024, length 291: HTTP, length: 291
	GET / HTTP/1.1
	Accept: text/html, application/xhtml+xml, image/jxr, */*
	Accept-Language: en-US
	User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; Trident/7.0; rv:11.0) like Gecko
	UA-CPU: AMD64
	Accept-Encoding: gzip, deflate
	Host: test2.castrolroadside.ca
	Connection: Keep-Alive
	
11:12:50.088793 00:1b:21:8b:15:80 > d8:9e:f3:12:77:6d, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 52, id 33045, offset 0, flags [DF], proto TCP (6), length 40)
    184.168.131.241.80 > 90.0.0.95.5329: Flags [.], cksum 0xa50e (correct), seq 1, ack 292, win 237, length 0
11:12:50.110807 00:1b:21:8b:15:80 > d8:9e:f3:12:77:6d, ethertype IPv4 (0x0800), length 268: (tos 0x0, ttl 52, id 33046, offset 0, flags [DF], proto TCP (6), length 254)
    184.168.131.241.80 > 90.0.0.95.5329: Flags [P.], cksum 0xf2ec (correct), seq 1:215, ack 292, win 237, length 214: HTTP, length: 214
	HTTP/1.1 301 Moved Permanently
	Server: nginx/1.12.2
	Date: Thu, 17 Oct 2019 15:12:50 GMT
	Content-Type: text/html; charset=utf-8
	Transfer-Encoding: chunked
	Connection: close
	Location: https://nsdmc.org
	
	0
	
11:12:50.110821 00:1b:21:8b:15:80 > d8:9e:f3:12:77:6d, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 52, id 33047, offset 0, flags [DF], proto TCP (6), length 40)
    184.168.131.241.80 > 90.0.0.95.5329: Flags [F.], cksum 0xa437 (correct), seq 215, ack 292, win 237, length 0
11:12:50.111038 d8:9e:f3:12:77:6d > 00:1b:21:8b:15:80, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 60469, offset 0, flags [DF], proto TCP (6), length 40)
    90.0.0.95.5329 > 184.168.131.241.80: Flags [.], cksum 0xa126 (correct), seq 292, ack 215, win 1023, length 0
11:12:50.111277 d8:9e:f3:12:77:6d > 00:1b:21:8b:15:80, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 60470, offset 0, flags [DF], proto TCP (6), length 40)
    90.0.0.95.5329 > 184.168.131.241.80: Flags [.], cksum 0xa125 (correct), seq 292, ack 216, win 1023, length 0
11:12:50.112451 d8:9e:f3:12:77:6d > 00:1b:21:8b:15:80, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 60471, offset 0, flags [DF], proto TCP (6), length 40)
    90.0.0.95.5329 > 184.168.131.241.80: Flags [F.], cksum 0xa124 (correct), seq 292, ack 216, win 1023, length 0
11:12:50.195320 00:1b:21:8b:15:80 > d8:9e:f3:12:77:6d, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 52, id 21203, offset 0, flags [DF], proto TCP (6), length 40)
    184.168.131.241.80 > 90.0.0.95.5329: Flags [.], cksum 0xa436 (correct), seq 216, ack 293, win 237, length 0
11:12:51.921420 d8:9e:f3:12:77:6d > 00:1b:21:8b:15:80, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 60472, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5330 > 184.168.131.241.80: Flags [S], cksum 0x2732 (correct), seq 509181290, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:12:52.004288 00:1b:21:8b:15:80 > d8:9e:f3:12:77:6d, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 52, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    184.168.131.241.80 > 90.0.0.95.5330: Flags [S.], cksum 0xa608 (correct), seq 4214035499, ack 509181291, win 29200, options [mss 1380,nop,nop,sackOK,nop,wscale 7], length 0
11:12:52.004520 d8:9e:f3:12:77:6d > 00:1b:21:8b:15:80, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 60473, offset 0, flags [DF], proto TCP (6), length 40)
    90.0.0.95.5330 > 184.168.131.241.80: Flags [.], cksum 0x549b (correct), seq 1, ack 1, win 1024, length 0

                          Packet capture from main pfsense (which does not work)

                          11:17:45.491015 d8:9e:f3:12:77:6d > 00:1b:21:8b:1f:70, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 21202, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5425 > 184.168.131.241.80: Flags [S], cksum 0xa19f (correct), seq 712767099, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:17:45.491016 d8:9e:f3:12:77:6d > 00:1b:21:8b:1f:70, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 21203, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5424 > 184.168.131.241.80: Flags [S], cksum 0x1674 (correct), seq 3340887297, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:17:46.491139 d8:9e:f3:12:77:6d > 00:1b:21:8b:1f:70, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 21204, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5424 > 184.168.131.241.80: Flags [S], cksum 0x1674 (correct), seq 3340887297, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:17:46.491143 d8:9e:f3:12:77:6d > 00:1b:21:8b:1f:70, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 21205, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5425 > 184.168.131.241.80: Flags [S], cksum 0xa19f (correct), seq 712767099, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:17:48.491019 d8:9e:f3:12:77:6d > 00:1b:21:8b:1f:70, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 21207, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5425 > 184.168.131.241.80: Flags [S], cksum 0xa19f (correct), seq 712767099, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:17:48.491020 d8:9e:f3:12:77:6d > 00:1b:21:8b:1f:70, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 21206, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5424 > 184.168.131.241.80: Flags [S], cksum 0x1674 (correct), seq 3340887297, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:17:52.491185 d8:9e:f3:12:77:6d > 00:1b:21:8b:1f:70, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 21208, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5426 > 184.168.131.241.80: Flags [S], cksum 0xa1c9 (correct), seq 1107156686, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:17:53.491645 d8:9e:f3:12:77:6d > 00:1b:21:8b:1f:70, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 21209, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5426 > 184.168.131.241.80: Flags [S], cksum 0xa1c9 (correct), seq 1107156686, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:17:55.492233 d8:9e:f3:12:77:6d > 00:1b:21:8b:1f:70, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 21210, offset 0, flags [DF], proto TCP (6), length 52)
    90.0.0.95.5426 > 184.168.131.241.80: Flags [S], cksum 0xa1c9 (correct), seq 1107156686, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
                          1 Reply Last reply Reply Quote 0
                          • S
                            scottys
                            last edited by

                            bump.

                            I have gone through every setting I can think of from outing to NAT to firewall rules to where it might be getting blocked, and I can't find anything. Anyone run into issues like this?

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

                              Where exactly did you take those captures?

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