To update this question: It appears as though to have the packet that is routed out another interface /towards another router, it has to be source-natted to the IP address belonging to that interface. so an additional command is: iptables -t nat -POSTROUTING -o tun0 -J SNAT --to-source 10.8.0.6 However it appears as though now my packets reach the destination and also get sent back to the correct address, they are not handled by the application/ they seem to be dropped?.. There is not actually anything happening when I do journalctl -xe. When I tcpdump I get the following (have to disconnect this because the routing will cease, brb.) (back). tcpdump -i tun0 -n will give: 19:27:06.541928 IP 10.8.0.6.41152 > 85.17.251.149.21: Flags [S], seq 161192099, win 29200, options [mss 1460,sackOK,TS val 170192065 ecr 0,nop,wscale 1], length 0 19:27:06.574683 IP 85.17.251.149.21 > 10.8.0.6.41152: Flags [S.], seq 1464228590, ack 161192100, win 28960, options [mss 1366,sackOK,TS val 1908182159 ecr 170192065,nop,wscale 7], length 0 19:27:07.573955 IP 85.17.251.149.21 > 10.8.0.6.41152: Flags [S.], seq 1464228590, ack 161192100, win 28960, options [mss 1366,sackOK,TS val 1908182409 ecr 170192065,nop,wscale 7], length 0 19:27:09.773560 IP 85.17.251.149.21 > 10.8.0.6.41152: Flags [S.], seq 1464228590, ack 161192100, win 28960, options [mss 1366,sackOK,TS val 1908182959 ecr 170192065,nop,wscale 7], length 0 19:27:13.974007 IP 85.17.251.149.21 > 10.8.0.6.41152: Flags [S.], seq 1464228590, ack 161192100, win 28960, options [mss 1366,sackOK,TS val 1908184009 ecr 170192065,nop,wscale 7], length 0 19:27:21.973331 IP 85.17.251.149.21 > 10.8.0.6.41152: Flags [S.], seq 1464228590, ack 161192100, win 28960, options [mss 1366,sackOK,TS val 1908186009 ecr 170192065,nop,wscale 7], length 0 The first packet is mine, the others are returns from the server. This is an attempt at opening an ftp session. The server keeps sending the same packet (same seq id). They are not getting through, although they are received. Does anyone know how to interpret this? I have already relaxed the source routing thing: sysctl -w net.ipv4.conf.tun0.rp_filter=0 sysctl -w net.ipv4.conf.all.rp_filter=0 Still my packets are going out, they are coming back, and yet they are dropped or prevented from arriving. I don't know how to interpret that. Regards, B. On Sun, 23 Aug 2015, Xen wrote:
I have been checking out ways to route certain ports directly to the web instead of going through my VPN (as a client).
The answer seems to be:
- create a firewall rule in the OUTPUT chain for the mangle table that sets a forward mark (fwmark) for conntrack (probably)
- add another table to /etc/iproute2/rt_tables (mine is identifier 1 with name "open")
- execute a command to add a rule for fwmark 1 to go to table 1 - add the default route you need to table 1:
ip route flush table 1 ip route add default table 1 via <router> ip rule add fwmark 1 table 1 ip route flush cache iptables -t mangle -F iptables -t mangle -A OUTPUT -p tcp -m multiport --dport 80,443 -m state --state NEW -j MARK --set-mark 1
However as soon as I add the route to the table while my VPN is up, all connections to port 80 (and 443 supposedly) cease. The moment I delete the route, I get a connection again.
my main table (254) at that point contains like:
default via 10.8.0.5 dev tun0 proto static default via <router> dev wls1 proto static metric 1024 10.8.0.0/24 via 10.8.0.5 dev tun0 proto static metric 20 10.8.0.1 via 10.8.0.5 dev tun0 proto static metric 20 10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6 <vpn gateway> via <router> dev wls1 127.0.0.1 via <router> dev wls1 128.0.0.0/1 via 10.8.0.5 dev tun0 proto static metric 20 192.168.1.0/24 via 10.8.0.5 dev tun0 proto static metric 20 192.168.99.1 via <router> dev wls1 proto dhcp metric 10 192.168.100.0/22 dev wls1 proto kernel scope link src 192.168.103.203
The second default route is an anomaly since NetworkManager will insist that its default route is present in the table; you can't delete it (I am now running openvpn directly).
If I run the VPN through NetworkManager that default route is gone.
Nevertheless, it's all the same: with my default route for ports 80,443 in the table 1 routing table I get no connections. The irony is that normally I don't have access to anything other than 80,443. Now with this setup, I have access to everything EXCEPT 80,443. Time to test that:
And indeed, my port 21 still works while port 80 (both outgoing) doesn't.
However, the moment I delete my VPN route from that table above (the first default) THEN suddenly I DO have access.
As if it can't decide what route to use and defaults on using neither ;-).
At that point my ip rule table looks as follows:
$ ip rule show 0: from all lookup local 32764: from all fwmark 0x1 lookup open 32766: from all lookup main 32767: from all lookup default
Basically, the elemental part of table "open" (1) is:
$ ip route show table 1 default via <router> dev wls1
That of table "main" (254) is:
$ ip route default via 10.8.0.5 dev tun0
But (for packages directed at table 1) apparently neither gets used and the latter conflicts with the former. I can't fully test it, because in this setup (direct openvpn from command line) NM won't allow me to delete the default route to <router>, and when using the KDE gui for NM, setting up VPN that way, it won't allow me to delete the default route to 10.8.0.5.
I would have to disable NM and do wpa_supplicant myself to fully test it.
So I can't test it with NO default route in the main table, but that's ridiculous, it should work with a default route and that is the whole purpose.
Nevertheless, in the current situation deleting this:
default via 10.8.0.5 dev tun0
effectively disables my VPN as far as routing goes and I immediately have access even with the table 1 route present.
Am I missing something? I don't really know how these tables cooperate but it is strange that when table 1 is (obviously) being used, table main is also still consulted, even when a default route has already been found.
Naturally, deleting the rule also immediately causes my connection to start (through the VPN, in this case, since it is routed).
Currently it only sets the mark on --state NEW but if I remove that I can also kill an ongoing connection by adding the route to the table :D.
So everything works that should work except the thing that should work :P.
What's going on here?.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org