Concentrator or something else?
-
I've hit a roadblock.
I added a rule to allow a specific user/IP to reach a server on the 10.0.0.0 network.
I allowed the IP on the server itself for ssh. I can see the remote vpn user hitting the server but not getting a response.
The firewalld rule; rule family="ipv4" source address="10.10.10.10/32" port port="22" protocol="tcp" accept # tcpdump -i ens18 src host 10.10.10.10 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens18, link-type EN10MB (Ethernet), capture size 262144 bytes 12:20:03.468302 IP 10.10.10.10.50526 > dev09.loc.ssh: Flags [S], seq 1895313320, win 8192, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0 12:20:06.465188 IP 10.10.10.10.50526 > dev09.loc.ssh: Flags [S], seq 1895313320, win 8192, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0 12:20:12.469257 IP 10.10.10.10.50526 > dev09.loc.ssh: Flags [S], seq 1895313320, win 8192, options [mss 1358,nop,nop,sackOK], length 0
Since other hosts can make it to the server's ssh, I'm not sure why this is not working.
-
@lewis said in Concentrator or something else?:
Since other hosts can make it to the server's ssh, I'm not sure why this is not working.
You have an any rule there at the bottom so yeah anyone would be able to go anywhere.. And rule that allows 10.10.10/24 to go anywhere as well
If you don't want them to get to ssh but only that .10 address, then create below your allow to ssh that specifically blocks to ssh.. or blocks all, etc.
-
Yes, I noticed that I have an extra/wrong rule but wasn't yet sure what to do so left it there.
Do you mean like this?
Since this still doesn't work, I guess I have to review rules I've made in the past on a multi network pfsense that allows traffic between nets.
-
@lewis that rule would allow specific only - nothing else would be allowed.. So for example if your trying to look up where you want to ssh via dns - dns wouldn't work.
But that rule would allow that source IP to talk to that destination IP on 22 only.
Keep in mind just turning off a rule wouldn't actually block anything that already had a state.
-
Yes, that's what I'm after, a rules based access to specific resources.
This first user should have access to certain hosts and ports only.
The split network aspect is perfect for this setup.Now, I'm still not sure why this rule is not working then. It's forwarding to the 10.0.0.9 server and I see the incoming connection but is never completes.
-
@lewis Well does this 10.0.0.9 box know how to get back to this 10.10.10 network, its gateway is pfsense?
Does this 10.0.0.9 box have its own firewall?
-
It does. I shared it a few comments ago.
The firewalld rule;
rule family="ipv4" source address="10.10.10.10/32" port port="22" protocol="tcp" acceptI can see the remote hitting the server but oddly, it's not allowing it. Strange.
14:33:54.341956 IP 10.10.10.10.60188 > dev09.loc.ssh: Flags [S], seq 2394177693, win 8192, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0 14:33:57.348343 IP 10.10.10.10.60188 > dev09.loc.ssh: Flags [S], seq 2394177693, win 8192, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0 14:34:03.359242 IP 10.10.10.10.60188 > dev09.loc.ssh: Flags [S], seq 2394177693, win 8192, options [mss 1358,nop,nop,sackOK], length 0
-
@lewis so your firewall rule is wrong on the host.. Or its not listening on 22? Or maybe its sending it answer elsewhere?
Just because you see traffic via a sniff, doesn't mean the firewall actually allows it up the stack..
-
I understand but It's pretty weird to me that the firewall is allowing everything but this host.
I shared the rule output above. It's like all the other ones.
I think I know why this isn't working. It's because the firewall I set this up on is not on the same network as the server is. Meaning, the servers gateway is different so it's not routing back to this firewall. I'll just move this config to the other one and it should be fine.At this point, it's not a pfsense issue so I think the post is done :).
-
I confirm. Everything is working now. The packets were going back to the wrong gw.
It's too bad the dashboard widget doesn't provide more information about the individual connections but I guess I can get that from some other program on the firewall like bandwidthd for example.Update: Nope, can't get that from bandwidthd.
All good now.