Can't SSH into machine with ipsec VPN

1

I have an ubuntu virtual machine with bridged adapter which I've configured to use an ipsec VPN. I can SSH into the machine just fine, but when I turn on the VPN, I can't. The VPN tunnel also makes the linux machine unresponsive to pings. The vm actually can't even ping its own gateway. My VPN provider does not provide port forwarding. What commands can I type to make sure I can still SSH in from the local network when the VPN is up?

Here is the output of initiating the tunnel from SSH and trying to use it as a socks proxy:

$ ssh -D 8123  -C -q -t -v ubuntu@192.168.1.27 "sudo ipsec up NordVPN"

authentication of 'us993.nordvpn.com' with EAP successful
IKE_SA NordVPN[9] established between 192.168.1.27[192.168.1.27]...23.81.21.124[us993.nordvpn.com]
scheduling reauthentication in 10085s
maximum IKE_SA lifetime 10625s
installing DNS server 78.46.223.24 via resolvconf
installing DNS server 162.242.211.137 via resolvconf
handling INTERNAL_IP4_NETMASK attribute failed
installing new virtual IP 10.6.6.231
debug1: Connection to port 8123 forwarding to socks port 0 requested.
debug1: channel 3: new [dynamic-tcpip]
debug1: Connection to port 8123 forwarding to socks port 0 requested.
debug1: channel 4: new [dynamic-tcpip]
debug1: Connection to port 8123 forwarding to socks port 0 requested.
debug1: channel 5: new [dynamic-tcpip]
debug1: Connection to port 8123 forwarding to socks port 0 requested.
debug1: channel 6: new [dynamic-tcpip]
debug1: Connection to port 8123 forwarding to socks port 0 requested.
debug1: channel 7: new [dynamic-tcpip]
debug1: Connection to port 8123 forwarding to socks port 0 requested.
debug1: channel 8: new [dynamic-tcpip]
packet_write_wait: Connection to 192.168.1.27 port 22: Broken pipe

ssh -v when the tunnel is already up just times out.

Nothing special in sshd_config?

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 1024
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin prohibit-password
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

sudo iptables -vpL (whether the VPN is up or down):

Chain INPUT (policy ACCEPT 41 packets, 9581 bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 37 packets, 6921 bytes)
 pkts bytes target     prot opt in     out     source               destination

Walrus the Cat

Posted 2017-12-03T20:50:22.877

Reputation: 240

You need to find out where the problem is. Pass SSH the -v directive and let us know what it says. Also, providing a copy of your /etc/ssh/sshd_config file from the server and iptables -vnL will allow us to look at the server side config and firewall rules and maybe shed some insite on the problem. The problem might also be an MTU issue. – davidgo – 2017-12-03T23:20:52.793

hey thanks @davidgo . posted the requested info. let me know what you think! – Walrus the Cat – 2017-12-04T06:00:56.957

@davidgo added a couple pieces of info: The VPN tunnel also makes the linux machine unresponsive to pings. The vm actually can't even ping its own gateway. – Walrus the Cat – 2017-12-04T20:22:43.193

I'm guessing that when you are bringing up the IPSec tunnel its changing your routing, such that you can no longer access the box via your original connection. One solution would be to prefix the ipsec command with a command which routes your home (or local/office) address out the ethernet interface, so that when the default gateway is replaced the route still finds its way back. – davidgo – 2017-12-04T20:40:47.673

it's apparently assigning me an internal ip of a different schema 10.0.0.26 which I can ping, and I can ping my own ip 192.168.1.27 but i can't ping 192.168.1.1 . what commands might you type to fix? – Walrus the Cat – 2017-12-04T20:46:53.060

No answers