0

I have configured the following s2s VPN (in pfSense) connection which is working in general.

enter image description here

Unfortunately, I can connect (ping, netcat, ssh) only from client to the server, but not back.

If I can ssh normally, it means that firewall is not the problem, right? Since packages are travelling in both directions?

How to diagnose the problem with the means of command line tools?

I made a mistake, I can't netcat backwards. But I can see ping traffic with packet capture on a client when pining it from server.

Also, I did add explicit route

route add -net 192.168.31.0/24 192.168.27.2

on a server.

Here is what I see when dumping packets on client when pinging it (.31.1) or it's network counterpars (.31.155) from the server

$ tcpdump -n -i ovpnc2 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpnc2, link-type NULL (BSD loopback), capture size 262144 bytes
20:04:44.123925 IP 192.168.27.1 > 192.168.31.1: ICMP echo request, id 14862, seq 0, length 64
20:04:45.133435 IP 192.168.27.1 > 192.168.31.1: ICMP echo request, id 14862, seq 1, length 64
20:04:46.146100 IP 192.168.27.1 > 192.168.31.1: ICMP echo request, id 14862, seq 2, length 64
20:04:49.664935 IP 192.168.27.1 > 192.168.31.155: ICMP echo request, id 1295, seq 0, length 64
20:04:50.663422 IP 192.168.27.1 > 192.168.31.155: ICMP echo request, id 1295, seq 1, length 64
20:04:51.679393 IP 192.168.27.1 > 192.168.31.155: ICMP echo request, id 1295, seq 2, length 64
20:04:52.688367 IP 192.168.27.1 > 192.168.31.155: ICMP echo request, id 1295, seq 3, length 64

Apparently, a client end sees ping packets, but doesn't respond, right?

Improve this question
2
  • As far as I can say, it does. Commented Mar 3, 2023 at 7:52
  • Either the ping target does not respond, or the response gets dropped somewhere between the target and the system that's doing the dumping. Commented Mar 3, 2023 at 19:59

1 Answer 1

Reset to default
1

A firewall can certainly control the direction TCP connections can be established in, by passing TCP packets with the SYN flag set but the ACK flag unset in one way only.

The fact that you can SSH normally only indicates that packets either with no SYN flag at all or with both SYN and ACK flags set are allowed in both directions. To establish a TCP connection, a system must send a packet with the TCP SYN flag set and ACK flag unset, and a firewall can easily tell these apart from other packets.

Pings are ICMP packets, not TCP packets, so a firewall can easily have a different rule for them. Also, a firewall could easily have one rule for "ping requests" and a different rule for "ping responses".

Improve this answer
3
  • Using command line (in FreeBSD), how to (1) ensure 100% that firewall is rejecting ICMP packets (2) see/modify acting firewall rules Having here it is VPN, and packets probably not jump between media correctly, (3) can we be sure only firewall can be responsible. Commented Mar 3, 2023 at 17:03
  • @Dims Please edit your question to add those additional details to your query Commented Mar 3, 2023 at 19:23
  • @JimL. it was in the question from the very beginning. Anyway, you were right, it was firewall. I was able to see this with ping and tcpdump -i SMTH icmp on various hosts. Commented Mar 3, 2023 at 23:06

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.