0

Here's a weird one.

Whenever I'm on a hotel network I tend to like to route all my traffic through my home network. Mainly since I'm not entirely sure all my passwords go through SSL all the time.

So I've got the following OpenVPN server settings:

persist-key 
dev tap
keepalive 10 120
port 1194
verb 3
status openvpn-status.log
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DNS 8.8.8.8"
persist-tun 
dh dh2048.pem
cert vpnserver.crt
key vpnserver.key
tls-auth ta.key 0
ca ca.crt
proto udp
comp-lzo 
cipher AES-128-CBC
ifconfig-pool-persist ipp.txt
client-to-client

Which works fantastic with these iptable rules: (It's under testing, so there's some stuff in here that's not really cleaned up.. But as of now I can't touch any of these to work out which should stay and which should go cause i'm on a trip right now..)

*nat
:PREROUTING ACCEPT [1152:137606]
:INPUT ACCEPT [835:107096]
:OUTPUT ACCEPT [161:11725]
:POSTROUTING ACCEPT [40:2585]
-A POSTROUTING -s 10.8.0.0/24 -o enp2s0 -j MASQUERADE
# ==
# == ROUTING
# ==
-A POSTROUTING -o enp2s0 -j MASQUERADE
# ==
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:TCP - [0:0]
:UDP - [0:0]
:fw-interfaces - [0:0]
:fw-open - [0:0]
# ==
# == BRIDGE ROUTING
# ==
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j fw-interfaces
-A FORWARD -j fw-open
-A FORWARD -j REJECT --reject-with icmp-host-unreachable
# ==
# == Accepts
# ==
-A TCP -p tcp -m tcp --dport 80 -j ACCEPT
-A TCP -p tcp -m tcp --dport 443 -j ACCEPT
-A TCP -p tcp -m tcp --dport 22 -j ACCEPT
-A UDP -p udp -m udp --dport 53 -j ACCEPT
# ==
# == Forwards
# ==
-A fw-interfaces -i tap0 -j ACCEPT
# == VPN route
-A FORWARD -i enp2s0 -o tap0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tap0 -o enp2s0 -j ACCEPT
# == VPN
-A INPUT -p udp -m state --state NEW,RELATED,ESTABLISHED -m udp --dport 1194 -j ACCEPT
-A OUTPUT -p udp -m state --state RELATED,ESTABLISHED -m udp --sport 1194 -j ACCEPT
# == DNS
-A INPUT -i enp2s0 -p udp -m state --state RELATED,ESTABLISHED -m udp --sport 53 -j ACCEPT
-A OUTPUT -o enp2s0 -p udp -m udp --dport 53 -j ACCEPT
# == WEB-outgoing
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 443 -j ACCEPT
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 80 -j ACCEPT
# == WEB-incomming
-A INPUT -p tcp -m tcp -m state --state NEW,RELATED,ESTABLISHED --dport 80 -j ACCEPT
-A OUTPUT -p tcp -m tcp -m state --state ESTABLISHED,RELATED --sport 80 -j ACCEPT
# ==
# == TAP0
# ==
-A INPUT -i tap0 -p udp -m state --state RELATED,ESTABLISHED -m udp --sport 53 -j ACCEPT
-A OUTPUT -o tap0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i tap0 -p udp --dport 67 -j ACCEPT
#-t nat -A POSTROUTING -s 10.8.0.0/24 -o enp2s0 -j MASQUERADE
-A FORWARD -i tap0 -s 10.8.0.0/24 -o enp2s0 -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# ==
# == GENERIC
# ==
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT -i tap0 -j ACCEPT
-A FORWARD -i tap0 -j ACCEPT
# ==
# == REJECTS
# ==
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
COMMIT
*nat
-A POSTROUTING -s 192.168.1.0/24 -o enp2s0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o enp2s0 -j MASQUERADE
COMMIT

# Generated by iptables-save v1.4.21 on Thu Jun  5 18:54:09 2014
*mangle
:PREROUTING ACCEPT [76747:82460059]
:INPUT ACCEPT [18221:1445339]
:FORWARD ACCEPT [58437:80998106]
:OUTPUT ACCEPT [17305:8505640]
:POSTROUTING ACCEPT [75742:89503746]
COMMIT
# Completed on Thu Jun  5 18:54:09 2014
# Generated by iptables-save v1.4.21 on Thu Jun  5 18:54:09 2014
*nat
:PREROUTING ACCEPT [1152:137606]
:INPUT ACCEPT [835:107096]
:OUTPUT ACCEPT [161:11725]
:POSTROUTING ACCEPT [40:2585]
-A POSTROUTING -o enp2s0 -j MASQUERADE
COMMIT
# Completed on Thu Jun  5 18:54:09 2014
# Generated by iptables-save v1.4.21 on Thu Jun  5 18:54:09 2014
*filter
:INPUT ACCEPT [18037:1435358]
:FORWARD ACCEPT [58437:80998106]
:OUTPUT ACCEPT [17119:8490056]
-A FORWARD -i enp2s0 -o wlp3s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlp3s0 -o enp2s0 -j ACCEPT
COMMIT
# Completed on Thu Jun  5 18:54:09 2014

This only sort of works tho, because the traffic gets routed through the VPN for sure.
But the response traffic comes back outside of the VPN network for whatever reason, and that's not desired. I'm assuming the MASQUERADE lines are all wrong?

Here's an example:
enter image description here

But when I execute a trace, the response comes back outside of the VPN:
enter image description here

My routes are ok and my DNS is working, so again, I'm assuming I'm going about the MASQUERADE wrong in the iptables? Perhaps I've overcomplicated things trying to bridge traffic from two interfaces out on enp2s0 (I've cut out br0 with 192.168.1.0/24 just to shorten the rules a bit)

Edit: Here's my routes (wlp3s0=wifi):

[torxed@archie ~]$ ip route
0.0.0.0/1 via 10.8.0.1 dev tap0 
default via 192.168.1.254 dev wlp3s0 
10.8.0.0/24 dev tap0  proto kernel  scope link  src 10.8.0.2 
109.X.X.X via 192.168.1.254 dev wlp3s0 
128.0.0.0/1 via 10.8.0.1 dev tap0 
192.168.1.0/24 dev wlp3s0  proto kernel  scope link  src 192.168.1.81 

2 Answers 2

1

Your MASQUERADE rules are probably wrong.

You only masquerade traffic going out over enp2s0, not tap0. This apparently results in packets retaining the address of wlp3s0 as their source address, which would explain why your replies are coming in through there.

0

So, a few years later and a bit wiser. I found out the root problem. Masuerading the problem was only partially the issue, but my problem was mainly a misdiagnosed symptom.

So to masquerade I followed this: https://unix.stackexchange.com/questions/283801/iptables-forward-traffic-to-vpn-tunnel-if-open

That gets you most of the way together with ip.net.ipv4.forwarding=1 in the kernel.
And then push "redirect-gateway def1 bypass-dhcp" makes sure the route is actually "overriding" the default gateway. And make sure you run your openvpn-client with elevated privileges or allow it to change routes.

Finally, my main issue was that I was using my own whats my ip service on the same server as the VPN exits on. Which makes the server do some internal routing optimizations and it will still tell me that I'm coming from my "un-vpn:ed" IP. Which was confusing as hell. That's what scratched my head for a long long time.

To boil the some what long iptables down, this is what I end up using:

iptables -t nat -A POSTROUTING -o internet0 -j MASQUERADE
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i net0 -o internet0 -j ACCEPT

Taken from Arch Linux wiki for Internet sharing.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .