As I first saw the problem, my first thought was routing. And I spent a full day with experimenting with every other possible crap, dunno why...
But you made it, and it is routing of course, why wouldn't it be.
Thank you!
]]>My solution so far has come from this resource http://forum.linode.com/viewtopic.php?t=8737
Since my server is behind a router, I do not have to worry about the public IP address changing and I was able to use the private IP in the route statements. Therefore, in my case, the solution was these three lines:
ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1
Keep in mind, as the article states, that applies to all ports (not just ssh). If you want to block other traffic, you need some extra iptables entries.
This also solves my end goal: Being able to connect to this 3rd party VPN with a simple ssh redirect from my always connected server. I can now ssh -D <port> <myhost>, set up chrome to use <port> as a proxy, and have everything redirecting over this VPN connection without any hassle.
meop, this setup is connecting to a 3rd party VPN service and they provided the config scripts for the client. I considered tinkering with that, but found this solution to work and I'm going to do some more reading about each solution to figure out which is the best overall.
enovak, I grepped dmesg and did not see any entries about martian source.
Now another question that comes to mind: What if this server were actually NOT behind a firewall and it's public IP changed? I think you'd somehow have to have a script to check to see if your Dynamic IP address changed and also have a route that only that script would use (send everything else out the VPN route). Then, if your IP address changed, you'd have to change these routes around. I'll leave that solution to someone else :-)
]]>Check dmesg. I think you'll see similar messages there, too:
Nov 3 20:12:20 miservar kernel: [3042107.444156] martian source 172.16.100.20 from xxx.xxx.xx.xxx, on dev eth0
Nov 3 20:12:20 miservar kernel: [3042107.444169] ll header: aa:0x:yz:dd:12:d0:bb:cc:dd:85:eb:2e:08:00
Nov 3 20:12:20 miservar kernel: [3042107.596523] martian source 172.16.100.20 from yyy.yyy.yy.yyy, on dev eth0
Nov 3 20:12:20 miservar kernel: [3042107.596537] ll header: aa:0x:yz:dd:12:d0:bb:cc:dd:85:eb:2e:08:00
So the problem is, the kernel sees the packets arriving on eth0 with the source address of the original sources' public IP, which is bad since eth0 has (in my fall) an subnet of 172.16.100.0/24, which is a private subnet.
I still have to figure out a solution for this - I'm afraid I can't make it without installing openwrt to my router.
Edit: might be a wrong clue - I set
sysctl -w "net.ipv4.conf.eth0.rp_filter=0"
sysctl -w "net.ipv4.conf.all.rp_filter=0"
and the martian source messages are no longer appearing, but ssh does still not work.
OK, your turn
]]>http://www.tinc-vpn.org/examples/redirect-gateway/
Is your OpenVPN client configured with '--redirect-gateway'? Is the 'def1' option set?
Based on what the OpenVPN manual describes as the effect of those settings and what seems like an overridden default gateway in your routing table, it looks like it. If you removed those settings, it would be a good start.
As for other routes, it would be easier if you had control of what routes the VPN service, or server, sends to your OpenVPN client on the Arch box. The server can push over any static routes it wants to the OpenVPN client, and the OpenVPN client will simply dump them all in the routing table. This is harder to filter or control client-side.
]]>Now I'd like to setup OpenVPN on the arch box to connect to a 3rd party vpn service but still listen for ssh connections. This way I can have my arch box always connected to the vpn but be able to access it from anywhere. I believe the problem is that openvpn sets up a default route to send all outgoing traffic out over the tunnel, but I don't know enough about routing to make this work. I saw another solution in the forum was running virtualbox and I find that so inelegant. I'm planning on eventually learning more about ip route and iptables but I was also hoping that a networking guru could help me get this set up quickly in the meantime.
ip route while not connected to vpn
default via 192.168.1.1 dev eth0 metric 202
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.11 metric 202
ip route while connected to vpn
0.0.0.0/1 via 10.120.62.9 dev tun0
default via 192.168.1.1 dev eth0 metric 202
10.120.62.1 via 10.120.62.9 dev tun0
10.120.62.9 dev tun0 proto kernel scope link src 10.120.62.10
23.29.126.102 via 192.168.1.1 dev eth0
128.0.0.0/1 via 10.120.62.9 dev tun0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.11 metric 202