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

    PFSense [RST, ACK] packet when accessing a site

    Scheduled Pinned Locked Moved General pfSense Questions
    28 Posts 5 Posters 3.8k 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.
    • 4
      4o4rh @stephenw10
      last edited by

      Hey guys,

      i have a freenas jail with weewx listening on port 8000. it sits on the server vlan.
      the weather station client sits on the client vlan.

      i am seeing the same thing when i capture from pfsense.

      if i connect the weather station to a ubuntu server on the same vlan, i do not have this problem. However, in this case the client (wifi) is connected to a managed switch so would bypass pfsense.

      In other words, i can't rule out pfsense nor clearly the freenas server/jail.

      given freenas and pfsense are both freebsd, can you give me some direction on how i can ensure it is not the freenas jail or pfsense causing this please.

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

        What exactly are you seeing?

        The server sends RST?

        Most likely it's configured not to accept connections from outside it's subnet.

        Steve

        4 1 Reply Last reply Reply Quote 0
        • 4
          4o4rh @stephenw10
          last edited by

          @stephenw10 captured on pfsense, the RST, ACK is marked red.

          22 2.968670 WH2900C WEEWX TCP 58 20150 → 8080 [SYN] Seq=0 Win=5840 Len=0 MSS=1460
          23 2.969709 WEEWX WH2900C TCP 54 8080 → 20150 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0]

          I have ping to each other from each system. both lie in different VLANs

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

            Right, it's refusing the connection. Nothing to do with pfSense which is routing it correctly.

            Since it's sending a RST rather then just dropping the traffic it's probably a server config issue but it could be a local firewall on the server.

            Steve

            4 1 Reply Last reply Reply Quote 0
            • 4
              4o4rh @stephenw10
              last edited by

              @stephenw10 i am not so strong with freebsd. can you offer some advice on commands that could help in identifying the cause pls

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

                You will need check whatever you have WeeWX running on. The server config there is the first place I would look.
                Could be something in FreeNAS rejecting it.

                To prove it you could add an outbound NAT rule in pfSense so traffic appears to be coming from the same subnet. If you can then access it you know it's a server side problem.

                Steve

                4 1 Reply Last reply Reply Quote 0
                • 4
                  4o4rh @stephenw10
                  last edited by

                  @stephenw10 so you mean like?

                  src Port Dst Port NAT Port
                  WH2900C 8000 WEEWX 8000 SRV_Address *

                  thx

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

                    If SRV_Address is the interface address on the VLAN where the server is.

                    You need an outbound NAT rule not a port forward.

                    Steve

                    johnpozJ 4 2 Replies Last reply Reply Quote 0
                    • johnpozJ
                      johnpoz LAYER 8 Global Moderator @stephenw10
                      last edited by

                      When you see a RST internally, its almost always going to be the OS of the device your trying to talk to. A firewall like pfsense, normally would never send a RST.. Unless you have a real specific rule setup to "reject" Which you really would rarely want on wan side. Internally such rules can be useful..

                      There some special use cases for reject on wan. If you want it to answer for traceroute for example is one that comes to mind. But normally a RST means you talked to OS, or OS firewall.. Since normally a firewall between you and your end device wouldn't send RST for traffic it doesn't allow. Default is normally to just drop traffic that is not allowed.

                      An intelligent man is sometimes forced to be drunk to spend time with his fools
                      If you get confused: Listen to the Music Play
                      Please don't Chat/PM me for help, unless mod related
                      SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                      4 1 Reply Last reply Reply Quote 0
                      • 4
                        4o4rh @stephenw10
                        last edited by 4o4rh

                        @stephenw10 so check "do not NAT"? like below?

                        Interface 	Source 	Source Port 	Destination 	Destination Port 	NAT Address 	NAT Port 	Static Port 	Description 	Actions
                          	VLAN_2_INTERN 	192.168.2.5/32 	8000 	192.168.4.7/32 	8000 	NO NAT		* 		TEST WEEWX Rule
                        
                        1 Reply Last reply Reply Quote 0
                        • 4
                          4o4rh @johnpoz
                          last edited by

                          @johnpoz thanks to you and steve for the clarification. freenas is freebsd.

                          how can i establish what on the box is causing it?
                          e.g. ip tables, etc?

                          can you offer some commands i could use to validate pls

                          johnpozJ 1 Reply Last reply Reply Quote 0
                          • johnpozJ
                            johnpoz LAYER 8 Global Moderator @4o4rh
                            last edited by johnpoz

                            No what stephenw10 is talking about is a source nat to get around rules that might stop traffic to a device, where the traffic is from another network.

                            server is on vlanX 192.168.1.100 for example, and you want to talk to it from device on vlanY 192.168.2.200 for example.

                            If 1.100 does not allow access to its services, because of firewall, or lack of gateway for example. You can do a outbound, or source nat to trick the 1.100 device to think the traffic came from pfsense IP in vlanX, say 192.168.1.1

                            This is outbound nat, set on the vlanX interface to set the source of the traffic to pfsense IP address in that interface. Here is example I have setup to talk to 9.101 device on my network because it has no gateway. So to the device when I talk to it from my vpn... It thinks the traffic came from pfsense IP address 9.253

                            outboundnat.png

                            I would not suggest this, unless the reason you can not talk to the device is no gateway.. You need to adjust the firewall on the device your trying to talk to allow traffic from where your talking from.

                            An intelligent man is sometimes forced to be drunk to spend time with his fools
                            If you get confused: Listen to the Music Play
                            Please don't Chat/PM me for help, unless mod related
                            SG-4860 24.11 | Lab VMs 2.7.2, 24.11

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

                              Yes, that ^.

                              But, also yes, you can use that to prove where the problem is but you should fix it at the root which is probably the server config or some rule in the FreeNAS networking.

                              Steve

                              4 1 Reply Last reply Reply Quote 0
                              • 4
                                4o4rh @stephenw10
                                last edited by 4o4rh

                                @stephenw10 ok, guys. thanks. I can see the port 8000 is coming from the svr vlan gateway address now instead of the wh2900c. and it is still being reset.

                                So it is clear, it is the truenas 12.1 box (or the jail that the weewx is running in).

                                any chance to guide me here with your freebsd knowledge pls

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

                                  How exactly are you seeing that? In the state table? Packet capture?

                                  I would have expected the connection to succeed after being translated to the interface address.

                                  Steve

                                  4 1 Reply Last reply Reply Quote 0
                                  • 4
                                    4o4rh @stephenw10
                                    last edited by

                                    @stephenw10 packet capture instead of the wh2900c address from before, it shows the svr vlan gateway address. so both addresses are on the same network.

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

                                      Mmm, OK. Well if you are seeing traffic leave the interface the server is on and using the interface IP then pfSense is both routing and translating correctly.
                                      Something in the FreeNAS firewall or the server config is rejecting it for some other reason.

                                      Check the server logs. Are those requests actually getting that far?

                                      Steve

                                      4 1 Reply Last reply Reply Quote 0
                                      • 4
                                        4o4rh @stephenw10
                                        last edited by

                                        @stephenw10 thanks guys. i got it working. was an issue with the application.

                                        johnpozJ 1 Reply Last reply Reply Quote 1
                                        • johnpozJ
                                          johnpoz LAYER 8 Global Moderator @4o4rh
                                          last edited by

                                          @gwaitsi said in PFSense [RST, ACK] packet when accessing a site:

                                          i got it working. was an issue with the application.

                                          I would remove your source nat then.. I wouldn't recommend natting between local networks.

                                          An intelligent man is sometimes forced to be drunk to spend time with his fools
                                          If you get confused: Listen to the Music Play
                                          Please don't Chat/PM me for help, unless mod related
                                          SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                                          4 1 Reply Last reply Reply Quote 0
                                          • 4
                                            4o4rh @johnpoz
                                            last edited by

                                            @johnpoz already did, thanks :-)

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