Problem with incoming ssh connections and PPTP

apanloco · 06-03-2009, 02:53 PM

When I connect my server to a PPTP VPN (ppp0) it no longer accepts incoming ssh connections on the main ethernet interface (eth1) if (and this part is the weirdest) the connections come from outside the LAN. The only difference between the incoming packets according to Wireshark is the SOURCE IP.

My setup is like this:

{INTERNET} <=> {ROUTER, 192.168.1.1, forwards port 22 to SERVER} <=> {SERVER, 192.168.1.2, on LAN, has ssh service running}

The server has eth1 interface (192.168.1.1), and when I connect to PPTP VPN, also a ppp0 interface.

Now more details on the complicated and weird stuff:
If ppp0 is down, I can connect from INTERNET _and_ LAN to SERVER on eth1 without a problem. If I ppp0 is up, i can still connect to eth1 from LAN, but not from INTERNET. I have grabbed some Wireshark logs and the packets does arrive on eth1, but there simply is no response. I temporarily disabled firewall, so that is not it. The packets from INTERNET and LAN look identical to me except of course for the source IP. My guess is that the Kernel somehow blocks it, and there could be some /proc or /sys option to disable this unfortunate behavior.

If you've reached this far, THANKS. If any more information is required, please please ask. I can easily upload the Wireshark logs if needed. I _really_ need help with this.

EDIT: Running Ubuntu 9.04, and gnome-network-manager-pptp.

/A

Matir · 06-03-2009, 08:25 PM

What does the routing table look like once the PPTP connection is up? Most likely it's trying to route through the LAN and is not able to get out.

apanloco · 06-04-2009, 07:01 AM

Quote:

Originally Posted by Matir

What does the routing table look like once the PPTP connection is up? Most likely it's trying to route through the LAN and is not able to get out.

Thanks for the attention, the routing table with and without ppp0 up is here:

Code:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     1      0        0 eth1
5.0.0.0         *               255.0.0.0       U     0      0        0 ham0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
93.182.184.2    192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
93.182.184.2    192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
93.182.184.2    *               255.255.255.255 UH    0      0        0 ppp0
192.168.1.0     *               255.255.255.0   U     1      0        0 eth1
5.0.0.0         *               255.0.0.0       U     0      0        0 ham0
default         *               0.0.0.0         U     0      0        0 ppp0

NOTE: To test I did a Wireshark log on port 22 for all interfaces, and it did not show any outgoing packets on any interface. Only the incoming SYN TCP packets.

/A

Matir · 06-04-2009, 06:56 PM

So the machine you're trying to connect from is on the 192.168.1.0/24 subnet? What is the ham0 interface? I guess the wireshark dump is the next step: your routing table looks correct to me.

apanloco · 06-05-2009, 10:02 AM

Quote:

Originally Posted by Matir

So the machine you're trying to connect from is on the 192.168.1.0/24 subnet? What is the ham0 interface? I guess the wireshark dump is the next step: your routing table looks correct to me.

ham0 is the hamachi interface which is always connected. I just checked: when I disable hamachi the ham0 line disappears but the problem is the same.

The .pcap file can be downloaded here:
http://www.box.net/shared/m7q6eophki

The first three packets (from .210) are when connecting externally. It's three SYN packets which are never replied. Then, I connect internally (from .3) and the ssh connection is established. Note also that this capture is on interface ANY, so there really is no outgoing replies.

Thanks,
/A

apanloco · 06-05-2009, 04:21 PM

This is what I currently think is going on:
when the incoming [SYN] on eth1 is received, and the kernel is about to reply with a [SYN, ACK], the routing tables ("default") says that packets not for the internal LAN should go through ppp0. Since it makes no sense to reply on another interface the kernel discards it.
I might be wrong, but I really think I'm on to something. Now the big question is, how do you fix it...

/A

apanloco · 06-05-2009, 07:45 PM

After hours of reading i got it to work. My described problem is called "routing for multiple uplinks", and is solved by some additions to the routing rules. The following script solves my case:

Code:

da@brutus:~$ sudo echo "200     my_table" >> /etc/iproute2/rt_tables # to add the table, which is required for the script
da@brutus:~$ cat ./fix_pptp_routing.sh
#!/bin/bash

IF="eth1"
IP="192.168.1.2"
GW=192.168.1.1
NET=192.168.1.0/24
TABLE=my_table

# rinse
ip route flush table $TABLE
ip rule del from $IP table $TABLE

# fix table
ip route add $NET dev $IF src $IP table $TABLE
ip route add default via $GW table $TABLE

# add rule
ip rule add from $IP table $TABLE

What I do is route the packets that come in on the default interface out on that same interface. If these don't match the default is still ppp0 (like before, default route is ppp0). Now ssh (and other services) works both over ppp0 and eth1 =)

/A