0

Not sure how well I can describe my issue, so sorry if something doesn't come across as correct I have a OpenVPN server hosted at home, I have it setup and connecting fine from my phone where it gets a static IP

I want to setup IP controls on my network (so I can see the source of where traffic is coming from, eg phone vs laptop)

By default OpenVPN routes traffic though itself, so once traffic goes into the network it shows as the OpenVPN Servers IP

Research shows that you need to set as a TAP not TUN, but Android by default doesn't support that. So I looked at doing a 1:1 nat to give my external devices a "Internal" ip on my network

EG my phone, VPN 10.10.101.101, LAN 10.10.100.101

I have a VLAN Setup with the IP ranges set, and have set the 100.101 IP on my VPN servers interface.

I found a 1:1 nat rule and set that on my VPN server hoping it would take traffic from my phone over the VPN (10.10.101.101) and nat it to the LAN IP 10.10.100.101 However that doesn't seem to have worked.

Im getting the following error on my main router / firewall IPv4: martian source 157.240.8.13 from 10.10.101.101, on dev eth0 Which makes me think its not doing a NAT but passing though its source IP as the VPN IP

So now im at a bit of a loss

Is it even possible to do what I want using OpenVPN? Iv tried googling, but I can't seem to find exactly what im looking for

Thanks Thomas

Configs:

server.conf

port 443
proto udp
dev tun

ca ca.crt
cert crt.crt
key key.key 
tls-auth ta.key 0 
key-direction 0
dh dh2048.pem
cipher AES-256-CBC

server 10.10.101.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
push "dhcp-option DNS 192.168.99.40"

keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun

client-config-dir ccd

log         openvpn.log
log-append  openvpn.log
verb 3

Client.conf

client
dev tun
proto udp
remote VPN.Domain.com 443

resolv-retry infinite
nobind
persist-key
persist-tun
verb 3
cipher AES-256-CBC

redirect-gateway def1
remote-cert-tls server

IP Tables

iptables -vL -t filter
Chain INPUT (policy ACCEPT 4555 packets, 1080K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  tun+   any     anywhere             anywhere

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  197 12387 ACCEPT     all  --  tun+   any     anywhere             anywhere
    0     0 ACCEPT     all  --  tun+   eth1    anywhere             anywhere             state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  eth1   tun+    anywhere             anywhere             state RELATED,ESTABLISHED

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


iptables -vL -t nat
Chain PREROUTING (policy ACCEPT 4547 packets, 602K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 NETMAP     all  --  any    any     anywhere             10.10.100.0/24      10.10.101.0/24

Chain INPUT (policy ACCEPT 66 packets, 11890 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 5 packets, 334 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 83 packets, 5320 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 NETMAP     all  --  any    any     anywhere             10.10.101.0/24      10.10.100.0/24


iptables -vL -t mangle
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

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

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination


iptables -vL -t raw
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

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


iptables -vL -t security
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
3
  • By default OpenVPN routes traffic though itself, so once traffic goes into the network it shows as the OpenVPN Servers IP That is not true. The VPN subnet is only "hidden" if you do SNAT / MASQUERADE for it. By default (and more like Linux's default) the traffics would merely be forwarded, and you need return route on the default gateway (or each of the hosts) of your LAN for things to work (that is, they need to use the server as gateway for 10.10.101.0/24).
    – Tom Yan
    Commented Nov 4, 2019 at 2:02
  • @TomYan how do I set that up then If I have no IPTABLES rules then the traffic just stops at the TUN interface I can't find any examples on how to just "Pass" the traffic though The only examples i can find show masq Commented Nov 4, 2019 at 2:40
  • Traffics will not just stop at the TUN interface, unless your iptables is configured to drop traffics in the FORWARD chain, or if you haven't enabled IP forwarding via sysctl or so at all. As long as IP forwarding is enabled and allowed, where the traffics go depends on your routes.
    – Tom Yan
    Commented Nov 4, 2019 at 3:00

2 Answers 2

0

I want to setup IP controls on my network (so I can see the source of where traffic is coming from, eg phone vs laptop)

By default OpenVPN routes traffic though itself, so once traffic goes into the network it shows as the OpenVPN Servers IP

You don't need to do anything to make traffics from the VPN clients to be distinguishable in the LAN / to your main router. By default Linux (yeah it doesn't even have anything to do with OpenVPN but your firewall) does not do source NAT (overload or not) for traffics it forwards.

Research shows that you need to set as a TAP not TUN, but Android by default doesn't support that. So I looked at doing a 1:1 nat to give my external devices a "Internal" ip on my network

It seems like here's a misunderstanding. You thought if the clients have IPs that are "in the subnet" of your LAN, the "real" hosts in your LAN will know how to reach them automatically, but that is NOT true. The VPN clients are still "remote" hosts anyway as they can't be found via / reached directly on layer 2 (i.e. exchange of Ethernet frames) but needs to be reached via the OpenVPN server on layer 3 (i.e. IP forwarding). So it won't help even if you do "1:1 NAT" (and you seem to have done it wrongly anyway, even if what you supposed to work is considered, as I only saw destination NAT but not source NAT), as it does not achieve the same thing as tap does.

So what you really need, as far as I can understand, is nothing special but just a return route on your main router (i.e. make the server the gateway for your VPN subnet) that most of the typical VPN setup needs when you don't want NAT overload (SNAT/MASQUERADE). It doesn't seem to me that you even needed tap anyway.

EDIT: Based on the "martian errors" you saw, I suppose your router only does NAT overload for traffics to the Internet from the LAN subnet (but not anything forwarded via a host in it that does not also do NAT overload for for it). As you would like to avoid the double NAT (so that you can "IP control", on your main router I suppose). You'll have to by some means make your router do NAT overload for traffics from the VPN subnet as well. If it can't be configured "properly" (like a SNAT/MASQUERADE iptables rule with a source match), then you will need to workaround it by "expanding" the LAN subnet so that it covers the VPN subnet, while configure the DHCP server to lease IP from the original range only (the upper half of the new LAN subnet). So in your example, just set the subnet mask / prefix length of the LAN to 255.255.254.0 / /23, and the set the DHCP range to 10.10.100.2-10.10.100.255. With that the VPN clients can use 10.10.101.0/24 without conflicting with the LAN hosts. You should be able to add static route for it as it shouldn't conflict with the subnet route (10.10.100.0/23) of the LAN either, but still overrides part of it (with the VPN server as gateway).

1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Mokubai
    Commented Nov 4, 2019 at 7:05
0

To answer my question
I had issues with the OpenVPN routing down eth0 even though eth1 was set as default

Moved my management interface to eth1 and my LAN to eth0 and traffic worked fine now

You must log in to answer this question.

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