PFSense [RST, ACK] packet when accessing a site
-
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
-
@stephenw10 i am not so strong with freebsd. can you offer some advice on commands that could help in identifying the cause pls
-
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
-
-
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
-
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.
-
@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 -
@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
-
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
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.
-
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
-
@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
-
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
-
@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.
-
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
-
@stephenw10 thanks guys. i got it working. was an issue with the application.
-
@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.
-
@johnpoz already did, thanks :-)
