TCP:SA Block and Default Deny Rule 1000000103

pomegranatesculpordwarffargo

Hi Everyone,
This one is driving me nuts.
I have my NAS (Unraid) on 10.0.100.30 and I am trying to see my unifi gui using my VM (Windows) from 10.0.101.20.

*Note VM and unifi controller (being run in docker) are both on NAS.
**Using vlans as well

Pfsense blocks the connection with the following:

Interface: Network_100
Rule: Default deny rule IPv4 (1000000103)
Source: 10.0.100.30:8080
Destination: 10.0.101.20:51065
Protocol: TCP:SA

The destination port number also keeps changing.

Thanks for any ideas or help any one can offer.

johnpoz

@pomegranatesculpordwarffargo said in TCP:SA Block and Default Deny Rule 1000000103:

Protocol: TCP:SA

Such blocks scream asymmetrical traffic..

So 10.0.101.20 is trying to talk to 10.0.100.30 and sent it a SYN to open up a connection on port 8080.. So 10.0.100.30 answering back its syn,ack sent it to pfsense, but pfsense didn't ever see the SYN..

pomegranatesculpordwarffargo

@johnpoz said in TCP:SA Block and Default Deny Rule 1000000103:

asymmetrical traffic

Thanks for the quick reply and narrowing down to asymmetric traffic problem.

I'm still new to pfsense, any approach or strategy you used to go about fixing it?
Its weird because the plex web gui in the same setup works fine.

Thanks again and appreciate any thoughts you have.

johnpoz

@pomegranatesculpordwarffargo going to need more to go on here.

When 10.0.101.20 sent a syn to 10.0.100.30 why did it not go thru pfsense? Is there some other router in play here?

Wrong mask? Where 100.30 and 101.20 are really on the same L2 network, so 20 could talk to 30, but 30 said oh I Need to send the answer to pfsense?

pomegranatesculpordwarffargo

@johnpoz Nope no other router in play strickly pfsense, netgear switch and unraid (nas) box.

10.0.101.20 (Windows VM running on unraid) is on a vlan and unraid is on its own seperate vlan.
Masks and L2 network look good and certain webui's like plex will work.

johnpoz

@pomegranatesculpordwarffargo Well something not like you think, because if they were you wouldn't be blocking on SA... which means pfsense never saw the original SYN.

Lets see a traceroute from 10.0.101.20 to 10.0.100.30

pomegranatesculpordwarffargo

@johnpoz Ah! Ok you're right as expected!

Traceroute is fine for 10.0.100.30 to really anywhere.
But 10.0.101.20 to 10.0.100.30 or anywhere else timesout.

Result
1 * * *
2 * * *
3 * * *
4 * * *

johnpoz

@pomegranatesculpordwarffargo said in TCP:SA Block and Default Deny Rule 1000000103:

But 10.0.101.20 to 10.0.100.30 or anywhere else timesout.

So you got something wrong there for sure - the first hit should be pfsense IP on that network..

So clearly something is not how you think it is..

Here is trace from one of my networks, to other network device.

$ tracert -d 192.168.2.12

Tracing route to 192.168.2.12 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.9.253
  2     1 ms    <1 ms    <1 ms  192.168.2.12

Trace complete.

First hop is pfsense IP, my gateway off 192.168.9/24, next hop is the destination.

Reverse..

traceroute to 192.168.9.10 (192.168.9.10), 64 hops max
  1   192.168.2.253  0.370ms  0.309ms  0.271ms 
  2   192.168.9.10  0.517ms  0.430ms  0.378ms 
user@NewUC:/$

Where 192.168.2.253 is pfsense IP on that 192.168.2/24 network..

pomegranatesculpordwarffargo

@johnpoz Thanks and yep! I get similair looking readouts from traceroute for 10.0.100.30 and acutally another vm on another vlan I got.

But 10.0.101.20 seems to be stubborn.

The subnet masks match in the dhcp server in pfsense.
So am I mistaken then that you're thinking the problem is in the L2 network or is there somewhere else I should be looking?

Thanks!

johnpoz

@pomegranatesculpordwarffargo you need to figure out why pfsense not seeing the syn.

If pfsense saw the syn, then it wouldn't be blocking the syn,ack - because there would be a state that allows it.

So simple test, is sniff on your source client there wanting to talk to 10.0.100.30, when you ping 10.0.100.30 where does it go?? In the sniff you will see the mac address it goes to, if that was pfsense mac address - then it would be seeing the syn, and wouldn't block the syn,ack..

A block of syn,ack is out of state traffic. So either pfsense never saw the syn to open the state.. Or the SA coming in on the wrong interface that it should be? And it doesn't match up to the state.. Look in your state table when you try and talk to the 100.30 box from 101.20 - do you see the state?

Are you states being reset, seems unlikely that is the reason or you would see blocks from other connections, etc.

Here if I talk to one of my vms on the 192.168.2.12 network, running on my NAS, from my 192.168.9.100 box..

I can see the state my 9.100 creates to 2.12 on port 8443, and then you see the response.

pomegranatesculpordwarffargo

@johnpoz Hi again, sorry had to step away for a bit.
Makes a lot of sense that that pfsense is not seeing the syn.
I can see a few successfuly states like yours:
10.0.101.20:51007 -> 10.0.100.30:443 ESTABLISHED:ESTABLISHED

But they're for port 443 which should be the NAS.

No port 8080 for gotify.

I'm with you that I don't think its the states. Seem like you say pfsense isn't even seeing the syn.
What sniff program do you recomend using?

johnpoz

@pomegranatesculpordwarffargo on your client wireshark works just fine.

johnpoz

@pomegranatesculpordwarffargo said in TCP:SA Block and Default Deny Rule 1000000103:

10.0.101.20:51007 -> 10.0.100.30:443 ESTABLISHED:ESTABLISHED

So you see it sending to pfsense to 10.0.30.443 for, which is your nas - but not for the vm on the same IP on port 8080?