ssh works but salt-ssh will be blocked with TCP:A

linuxfreak · Nov 1, 2020, 12:57 PM

hello everyone,
i have a problem and i dont no why. I had two pfsense connected over a network and they have also lan networks behind.
I added rules for routing and if i connect from my linux client to the linux server via ssh i got an connection.
But if i try to connect with salt-ssh the firewall will block with TCP:A.

Both commands uses the port 22/tcp.

johnpoz · Nov 1, 2020, 1:17 PM

@linuxfreak said in ssh works but salt-ssh will be blocked with TCP:A:

irewall will block with TCP:A.

Well that block is out of state.. Means there is no state to allow the traffic, a SYN is needed and has to be allowed to allow for the state to be created.

linuxfreak · Nov 1, 2020, 1:26 PM

Thank you for the quick answer but could you explain me what i need to do.

johnpoz · Nov 1, 2020, 1:57 PM

Well look to see why there was no syn sent? Or why a state you had open already was removed?

I would prob sniff on your client to see what is going on.. When you open tcp connection there will be a handshake.. client will send a syn, server will send back syn,ack etc..

https://www.geeksforgeeks.org/tcp-3-way-handshake-process/

If you see pfsense block on just A (ack)... Then means there is no current state to allow the traffic. So either is was never opened (pfsense never saw a syn), or it went away and the client doesn't know it did..

Seeing blocks on A, also can point to a asymmetrical traffic flow..
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html

edit: Here maybe this will be helpful... So you you can see here I ssh'd to a box on one of my vlan 192.168.3.32, from my pc 192.168.9.100

You see handshake syn/syn,ack/ack -- and then continuation of the conversation. You see from the pfsense state tables the states created after pfsense saw that syn, and it was allowed via firewall rules.

linuxfreak · Nov 1, 2020, 2:41 PM

I found my problem. I need to set "State type" to "sloppy" and now my connection works. Thank you fore your help.

johnpoz · Nov 1, 2020, 4:01 PM

@linuxfreak said in ssh works but salt-ssh will be blocked with TCP:A:

found my problem. I need to set "State type" to "sloppy" and now my connection works. Thank you fore your help.

Sorry but that is NOT a solution - that is a hack work around.. If the problem is your asymmetrical.. The FIX is to remove the asymmetrical traffic flow.

linuxfreak · Nov 1, 2020, 4:23 PM

i dont understand why i have this asymmetrical traffic. Normal ssh have no problem only ssh over saltstack.

Firewall 1:

Manage the MGNT Network (192.168.100.0/24)
-- Interface 192.168.100.30
Linux Client is in the same Network (192.168.100.40)
Gateway( Firewall2 ) : 192.168.100.20
static route : 192.168.110.0/24 over Gateway Firewall2

Firewall 2:

interfaces :
- MGNT 192.168.100.20
- LAN 192.168.110.1
local network (192.168.110.0/24)
Gateway (Firewall1) : 192.168.100.30

johnpoz · Nov 1, 2020, 4:42 PM

It may not be asymmetrical?

How about you draw up this network so we can see. But setting your firewall to allow for sloppy states is not a "fix" you shouldn't have to do that..

Sloppy states are for when you specifically have asymmetrical traffic - and there no way to not have it.. The correct solution is not to have asymmetrical flow..

How are these 2 firewalls connected?

Linux Client is in the same Network (192.168.100.40)

So you have a client in what is your transit network between these 2 firewalls? Yeah that is going to quite often have asymmetrical flow unless you setup host routing on this host in the transit network. Or your natting to get to networks behind the firewalls.

edit: this is your network?

What exactly is talking to what, and who is starting the conversation... But unless your natting or host routing on that box in the 192.168.100 - your going to end up with asymmetrical flow..

linuxfreak · Nov 1, 2020, 5:04 PM

Yes thats correct, but in the firewall rule of firewall 1 i set the gateway (firewall2). Is that not correct for routing?

johnpoz · Nov 1, 2020, 5:19 PM

That is fine - that is not the problem... The problem is your host is in the transit network... So unless you create a route on it that says how to get to the 110 network, its always going to be asymmetrical.. Because he will just send traffic to his gateway..

See the arrows.. Do they follow the same path? Red is start of convesation, green is answer.

You should not place hosts on a transit network.. A network that connects routers together.. Or your going to end up with asymmetrical traffic.

If you have host(s) in this 192.168.100 network - then use something else for transit 172.16.0/30 for example... Or move this host to another network.

linuxfreak · Nov 1, 2020, 5:22 PM

perfect now it works, thank you for helping me to understand the problem.

johnpoz · Nov 1, 2020, 5:24 PM

Something like this would be a better setup.

Now you do not need to do any host routing on devices, and you don't have to worry about nat between these rfc1918 networks. And your flow is always symmetrical

linuxfreak · Nov 1, 2020, 5:30 PM

i will move my client to an separate network, like your picture. i think thats the best way. thank you for the example.

johnpoz · Nov 1, 2020, 5:53 PM

Just keep in mind that if a network connects 2 or more routers together.. You don't put hosts on that network or any traffic to and from that host will be asymmetrical.. Unless you specifically tell the host which router to use to get to which network.. Or you nat so that the host on the transit only ever sees IPs from its own network.