IPFW Using SSH over VPN doesn't work

I am trying to connect to SSH from a VPN client to my FreeBSD server which is located on the LAN. Unless I am missing something, the fault seems to be with the FreeBSD server.

I can connect to it with no issues from within the LAN. Checking the traffic on the FreeBSD server with tcpdump I can see TCP SYN packets coming in from the VPN client when I try to connect, but no SYN ACK is going out. I even tried disabling the firewall with 'service ipfw stop' to see if I was missing some rule in the firewall, but I still get the same results. Any idea what might be at fault?
 
'service ipfw stop' to see if I was missing some rule in the firewall, but I still get the same results. Any idea what might be at fault?
With ipfw you do not need not to stop it. Just put the first rule in ipfw ipfw add 10 allow ip from any to any (assuming you have no rules before 10).

Do you have only ipfw(8) or pf(4) also configured?
 
I don't think I have pf configured. I have no entries for pf in my rc.conf file. Sorry, not very familiar with FreeBSD. Are there any specific logs I can check to see what the heck is going?
 
Checking the traffic on the FreeBSD server with tcpdump I can see TCP SYN packets coming in from the VPN client when I try to connect, but no SYN ACK is going out.
That's good, then you at least know it's going through the tunnel and nothing is blocking it somewhere along the path.

Are there any specific logs I can check to see what the heck is going?
For ssh(1) you will want to look at /var/log/auth.log. But I doubt anything is in there because there's no ACK response going out, so sshd(8) doesn't even handle the connection request. This would certainly point to a firewall not allowing the connection. Really old-school but have you checked /etc/hosts.allow?
 
Nothing auth.log. Can't see anything in the hosts.allow file either that would stop me :(

Tried connecting via the OpenVPN server from its VPN interface with the same results. For reference, the server is on an openwrt router and the client is an Android phone with the connectbot app.
 
One oddity I notice right now when doing verbose output from tcpdump is that the checksum from the outgoing packet is incorrect. On the VPN client it says: cksum 0xcc74 (incorrect -> 0x7ee3), but on the receiving FreeBSD server the checksum is correct cksum 0x7ee3 (correct). I am not sure what to make of this.
 
One oddity I notice right now when doing verbose output from tcpdump is that the checksum from the outgoing packet is incorrect. On the VPN client it says: cksum 0xcc74 (incorrect -> 0x7ee3), but on the receiving FreeBSD server the checksum is correct cksum 0x7ee3 (correct). I am not sure what to make of this.
Also, when running ssh from remote machine, use ssh -v. This will show you a number of ssh debug messages.
 
Can't see anything in the hosts.allow file either that would stop me
No, I didn't expect anything. If I recall correctly if it was denied there you would see a RST packet as a response.

On the VPN client it says: cksum 0xcc74 (incorrect -> 0x7ee3), but on the receiving FreeBSD server the checksum is correct cksum 0x7ee3 (correct). I am not sure what to make of this.
That's usually because of a hardware check being on or off (rxsum/txsum). That seems to throw tcpdump(1) off sometimes.
 
This is what I get with
ssh -b <client-ip> -vvv <server-ip>

OpenSSH_8.0p1, OpenSSL 1.1.1h 22 Sep 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname <server-ip> is address
debug2: ssh_connect_direct
debug1: Connecting to <server-ip> [<server-ip>] port 22.
debug1: ssh_create_socket: bound to <client-ip>
debug1: connect to address <server-ip> port 22: Operation timed out
ssh: connect to host <server-ip> port 22: Operation timed out


nothing that seems to help.
 
This is what I get with
ssh -b <client-ip> -vvv <server-ip>

OpenSSH_8.0p1, OpenSSL 1.1.1h 22 Sep 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname <server-ip> is address
debug2: ssh_connect_direct
debug1: Connecting to <server-ip> [<server-ip>] port 22.
debug1: ssh_create_socket: bound to <client-ip>
debug1: connect to address <server-ip> port 22: Operation timed out
ssh: connect to host <server-ip> port 22: Operation timed out


nothing that seems to help.
Seems that this is blocked on the server side.

See also service sshd restart and after that tail /var/log/auth.log
 
Yeah, but firewall is off and I can see SYN packet server side. Is there some other networking configuration I am missing considering VPN clients are on 10.0.0.0/24 and LAN is on 192.168.1.0/24, and I am connecting from 10.0.0.1 to 192.168.1.1?
 
Tried this, and it outputs nothing when I try to connect.
Should be something like this:

Code:
service sshd restart
Performing sanity check on sshd configuration.
Stopping sshd.
Waiting for PIDS: 1934.
Performing sanity check on sshd configuration.
Starting sshd.

and

Code:
Dec 17 14:54:52 xx Demo Demo[sshd]: - Received signal 15; terminating.
Dec 17 14:54:52 xx Demo Demo[sshd]: - Server listening on :: port 22.
Dec 17 14:54:52 xx Demo Demo[sshd]: - Server listening on 0.0.0.0 port 22.
 
Is there some other networking configuration I am missing considering VPN clients are on 10.0.0.0/24 and LAN is on 192.168.1.0/24, and I am connecting from 10.0.0.1 to 192.168.1.1?
You already verified the SYN arrives at its destination. So the route forward and any intermediate firewalls should be good. Even if the route back would be wrong you should still see the SYN/ACK response. That SYN/ACK would then never arrive at its destination but it would still be generated. The fact you don't see the SYN/ACK means sshd(8) doesn't receive anything. If it was due to a service not running (or not listening on that IP) you would get a RST in response (closed port). Because there's nothing being returned I'm still considering a firewall. That's the only reason why nothing would be returned (because the packet is dropped).
 
Okay, found the issue. A while back I tried setup an OpenVPN server on the FreeBSD machine, but never got around to using it and then forgot about it. Seems like I used the same 10.0.0.0/24 net for that and so there was a collision of addresses where both the VPN client and the FreeBSD server had 10.0.0.1 assigned to itself. Turned off openvpn, and now it works!

Stupid mistake on my end, but thanks for your help guys!
 
Back
Top