LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (http://www.linuxquestions.org/questions/linux-networking-3/)
-   -   policy routing for HTTP traffic over OpenVPN (http://www.linuxquestions.org/questions/linux-networking-3/policy-routing-for-http-traffic-over-openvpn-727511/)

mikeage 05-21-2009 07:19 AM

policy routing for HTTP traffic over OpenVPN
 
I have an OpenVPN server located on a VPS. It has one network card (eth0), with a public IP address. It runs an openvpn server, giving out addresses in the 192.168.2.x subnet.

I have a client connecting via a home router. The client's local IP address is 192.168.1.100, and it gets the address of 192.168.2.5 from the VPN server.

I can successfully access the VPN server from the client.

I have the following firewall rule(s) on the server:

Code:

mikeage@server ~$ sudo iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 1816 packets, 90836 bytes)
 pkts bytes target    prot opt in    out    source              destination

Chain POSTROUTING (policy ACCEPT 13133 packets, 824K bytes)
 pkts bytes target    prot opt in    out    source              destination
    3  180 MASQUERADE  all  --  any    eth0    192.168.2.0/24      anywhere

Chain OUTPUT (policy ACCEPT 13132 packets, 823K bytes)
 pkts bytes target    prot opt in    out    source              destination

mikeage@server ~$ sudo iptables  -L -v
Chain INPUT (policy DROP 3 packets, 168 bytes)
 pkts bytes target    prot opt in    out    source              destination
28026  12M ACCEPT    all  --  lo    any    anywhere            anywhere
45691  43M ACCEPT    all  --  eth0  any    anywhere            anywhere            state RELATED,ESTABLISHED
    0    0 ACCEPT    tcp  --  eth0  any    anywhere            anywhere            tcp dpt:ssh state NEW
  18  880 ACCEPT    tcp  --  eth0  any    anywhere            anywhere            tcp dpt:smtp state NEW
  56  3248 ACCEPT    tcp  --  eth0  any    anywhere            anywhere            tcp dpt:www state NEW
  10  600 ACCEPT    tcp  --  eth0  any    anywhere            anywhere            tcp dpt:https state NEW
    0    0 ACCEPT    tcp  --  eth0  any    anywhere            anywhere            tcp dpt:openvpn state NEW
    0    0 ACCEPT    icmp --  any    any    anywhere            anywhere
    0    0 ACCEPT    all  --  tap+  any    anywhere            anywhere
 3943  737K ACCEPT    all  --  tun+  any    anywhere            anywhere
  56  2008 REJECT    all  --  any    any    anywhere            anywhere            reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 4 packets, 240 bytes)
 pkts bytes target    prot opt in    out    source              destination
  18  1080 ACCEPT    all  --  any    tun+    anywhere            anywhere            state RELATED,ESTABLISHED
    3  180 ACCEPT    all  --  tun+  eth0    anywhere            anywhere            state NEW

Chain OUTPUT (policy ACCEPT 69421 packets, 24M bytes)
 pkts bytes target    prot opt in    out    source              destination

I want to send web (port 80 and 443) traffic from the client to the internet via the openvpn server, but have all other traffic leave the client via the default route (192.168.1.100 -> 192.168.1.1).

If I set up a fixed route to an internet site, I can get to the internet via the vpn:
Code:

mikeage@client ~% sudo /sbin/route add -host 74.125.45.100 gw 192.168.2.1
[in another window: wget http://74.125.45.100]
mikeage@client ~% sudo /usr/sbin/tcpdump -i tun0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 96 bytes
15:04:12.976945 IP 192.168.2.5.52196 > 74.125.45.100.80: S 422926017:422926017(0) win 5840 <mss 1460,sackOK,timestamp 1632623 0,nop,wscale 6>
15:04:13.169740 IP 74.125.45.100.80 > 192.168.2.5.52196: S 1800842449:1800842449(0) ack 422926018 win 5672 <mss 1366,sackOK,timestamp 564894277 1632623,nop,wscale 6>
15:04:13.169772 IP 192.168.2.5.52196 > 74.125.45.100.80: . ack 1 win 92 <nop,nop,timestamp 1632671 564894277>
15:04:18.887565 IP 192.168.2.5.52196 > 74.125.45.100.80: P 1:17(16) ack 1 win 92 <nop,nop,timestamp 1634101 564894277>
15:04:19.075521 IP 74.125.45.100.80 > 192.168.2.5.52196: . ack 17 win 89 <nop,nop,timestamp 564900184 1634101>
15:04:19.657798 IP 74.125.45.100.80 > 192.168.2.5.52196: P 1:163(162) ack 17 win 89 <nop,nop,timestamp 564900189 1634101>
15:04:19.657815 IP 192.168.2.5.52196 > 74.125.45.100.80: . ack 163 win 108 <nop,nop,timestamp 1634293 564900189>
15:04:19.657860 IP 74.125.45.100.80 > 192.168.2.5.52196: . 163:1517(1354) ack 17 win 89 <nop,nop,timestamp 564900189 1634101>
15:04:19.657872 IP 192.168.2.5.52196 > 74.125.45.100.80: . ack 1517 win 154 <nop,nop,timestamp 1634293 564900189>
15:04:19.657914 IP 74.125.45.100.80 > 192.168.2.5.52196: . 1517:2871(1354) ack 17 win 89 <nop,nop,timestamp 564900189 1634101>
15:04:19.657926 IP 192.168.2.5.52196 > 74.125.45.100.80: . ack 2871 win 199 <nop,nop,timestamp 1634293 564900189>
15:04:19.657968 IP 74.125.45.100.80 > 192.168.2.5.52196: . 2871:4225(1354) ack 17 win 89 <nop,nop,timestamp 564900189 1634101>
15:04:19.657982 IP 192.168.2.5.52196 > 74.125.45.100.80: . ack 4225 win 244 <nop,nop,timestamp 1634293 564900189>
15:04:19.815271 IP 74.125.45.100.80 > 192.168.2.5.52196: P 1:163(162) ack 17 win 89 <nop,nop,timestamp 564900750 1634101>
15:04:19.815285 IP 192.168.2.5.52196 > 74.125.45.100.80: . ack 4225 win 244 <nop,nop,timestamp 1634333 564900189,nop,nop,sack 1 {1:163}>
15:04:20.054009 IP 74.125.45.100.80 > 192.168.2.5.52196: . 4225:5579(1354) ack 17 win 89 <nop,nop,timestamp 564901159 1634293>
15:04:20.054029 IP 192.168.2.5.52196 > 74.125.45.100.80: . ack 5579 win 289 <nop,nop,timestamp 1634392 564901159>
15:04:20.214097 IP 74.125.45.100.80 > 192.168.2.5.52196: . 5579:6933(1354) ack 17 win 89 <nop,nop,timestamp 564901159 1634293>
15:04:20.214113 IP 192.168.2.5.52196 > 74.125.45.100.80: . ack 6933 win 335 <nop,nop,timestamp 1634432 564901159>
15:04:20.214135 IP 74.125.45.100.80 > 192.168.2.5.52196: FP 6933:7084(151) ack 17 win 89 <nop,nop,timestamp 564901159 1634293>
15:04:20.214397 IP 192.168.2.5.52196 > 74.125.45.100.80: F 17:17(0) ack 7085 win 377 <nop,nop,timestamp 1634432 564901159>
15:04:20.486693 IP 74.125.45.100.80 > 192.168.2.5.52196: . ack 18 win 89 <nop,nop,timestamp 564901593 1634432>
^C
22 packets captured
22 packets received by filter
0 packets dropped by kernel

However, I'd like to leave the route alone, and just mark the packets intended for port 80, and port 443 (right now I'm just doing 80), and create a route just for them

Code:

mikeage@client ~% sudo /sbin/route del 74.125.45.100 gw 192.168.2.1
mikeage@client ~% sudo iptables -t mangle -A OUTPUT -j MARK -p tcp --dport 80 --set-mark 80
mikeage@client ~% sudo ip route add table 200 default via 192.168.2.1
mikeage@client ~% sudo ip rule add fwmark 0x50 table 200
mikeage@client ~% sudo ip route flush cache
mikeage@client ~% sudo /usr/sbin/tcpdump -i tun0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 96 bytes
15:05:07.470646 IP 192.168.1.100.58073 > 74.125.45.100.80: S 1270174169:1270174169(0) win 5840 <mss 1460,sackOK,timestamp 1646246 0,nop,wscale 6>
15:05:10.467210 IP 192.168.1.100.58073 > 74.125.45.100.80: S 1270174169:1270174169(0) win 5840 <mss 1460,sackOK,timestamp 1646996 0,nop,wscale 6>
15:05:16.467218 IP 192.168.1.100.58073 > 74.125.45.100.80: S 1270174169:1270174169(0) win 5840 <mss 1460,sackOK,timestamp 1648496 0,nop,wscale 6>
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

Note that the source here is 192.168.1.100, which is wrong. tcpdump on the server shows the same thing (the same addresses)

If I enable NAT on the client as well:
Code:

mikeage@client ~% sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
Then I get the following, which looks a little better, but I still get a timeout on the client's wget.

Code:

mikeage@client~% sudo /usr/sbin/tcpdump -i tun0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 96 bytes
15:46:37.169338 IP 192.168.2.5.51810 > 74.125.45.100.80: S 1660332926:1660332926(0) win 5840 <mss 1460,sackOK,timestamp 2268715 0,nop,wscale 6>
15:46:37.364124 IP 74.125.45.100.80 > 192.168.2.5.51810: S 369374977:369374977(0) ack 1660332927 win 5672 <mss 1366,sackOK,timestamp 1451381315 2268715,nop,wscale 9>
15:46:37.708185 IP 74.125.45.100.80 > 192.168.2.5.51810: S 369374977:369374977(0) ack 1660332927 win 5672 <mss 1366,sackOK,timestamp 1451381659 2268715,nop,wscale 9>
15:46:38.307771 IP 74.125.45.100.80 > 192.168.2.5.51810: S 369374977:369374977(0) ack 1660332927 win 5672 <mss 1366,sackOK,timestamp 1451382259 2268715,nop,wscale 9>
15:46:39.507393 IP 74.125.45.100.80 > 192.168.2.5.51810: S 369374977:369374977(0) ack 1660332927 win 5672 <mss 1366,sackOK,timestamp 1451383459 2268715,nop,wscale 9>
15:46:41.908584 IP 74.125.45.100.80 > 192.168.2.5.51810: S 369374977:369374977(0) ack 1660332927 win 5672 <mss 1366,sackOK,timestamp 1451385860 2268715,nop,wscale 9>

I suspect that the return packets are not being accepted for some reason, although there's no firewall or anything on the client machine.

linusali 05-21-2009 08:13 AM

It is really a strange issue. May be I will try to simulate the scenario to see what is happening. I think we have to dig deeper into the packets.

Best Of Luck


All times are GMT -5. The time now is 08:37 PM.