Hello, Long time OpenVPN administrator, first time poster here. I have been employing for quite some time, at numerous sites, a site-to-site VPN using layer 3 tunnelling via TUN (not TAP) devices. My configurations typically look like this: [code] side a (LAN: 172.16.0.1) side b (LAN: 172.16.1.1) 172.16.0.0/24 172.31.0.1 172.16.0.2 172.16.1.0/24 side a tunnel IP side b tunnel IP [/code] Everything works both ways just fine, however, one annoying side effect of doing it this way is, if someone on side a communicates with a server on side b, the IP address that side b machine sees is side b's OpenVPN server LAN address, instead of the side a originating IP address. So, for instance if a machine on side a with an IP of 172.16.0.5 talks to a machine on side b who's IP address is 172.16.1.10, the logs, network traffic, etc. don't reflect that it's 172.16.0.5; instead the LAN address of side b is what the client on that network sees (172.16.1.1). So, the (sophomoric) question to be asked is, can we not show the gateway IP, but the real client IP's address? Because the tunnels are symmetric, both sides can communicate, such that any machines on 172.16.1.0/24 can directly access machines on 172.16.0.0/24, and vice-versa. side a config: [code] port 1194 proto tcp-server dev tun0 ca /etc/openvpn/CA/keys/ca.crt cert /etc/openvpn/CA/keys/sidea.cert key /etc/openvpn/CA/keys/sidea.key dh /etc/openvpn/CA/keys/dh2048.pem remote public.ip.of.side.b 1194 ifconfig 172.31.0.1 172.31.0.2 route 172.16.1.0 255.255.255.0 172.31.0.2 up /etc/openvpn/set-up-nat-and-routing.sh tls-server persist-key persist-tun cipher BF-CBC verb 5 comp-lzo float [/code] side b config [code] port 1194 proto tcp-client dev tun0 ca /etc/openvpn/CA/keys/ca.crt cert /etc/openvpn/CA/keys/sideb.crt key /etc/openvpn/CA/keys/sideb.key dh /etc/openvpn/CA/keys/dh2048.pem remote side.a.public.ip.address 1194 ifconfig 172.31.0.2 172.31.0.1 route 172.16.0.0 255.255.255.0 172.31.0.1 up /etc/openvpn/set-up-nat-and-routing.sh tls-client persist-key persist-tun cipher BF-CBC verb 5 comp-lzo float [/code] Beyond this config, the systems are configured to do ipv4 forwarding, and the appropriate iptables-based forwarding. I have tried playing with the values of [i]iptables -t nat -A POSTROUTING -o $INTERFACE -j MASQUERADE[/i] to not much avail (where $INTERFACE is the appropriate LAN interface). Any suggestions would be appreciated--this really isn't a problem, as much as an annoyance of gap in knowledge.

Hi Michael, Thanks for the response. I (re)tried your suggestion and turned NAT off via: [code] iptables -t nat -X iptabels -t nat -F [/code]and no traffic was passed. I selectively started adding NAT back to the tunnel, LAN, and WAN (public/external) interfaces; I have 3 NAT rules in the /etc/openvpn/set-up-nat-and-routing.sh script that look like so: [code] iptables -t nat -A POSTROUTING -o tun+ -j MASQUERADE iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE [/code] Realistically, the only one that seems to make a difference (after clearing out the NAT rules) is: [code] iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE [/code]...which yields the behavior I initially describe. [quote]why dont you use the server & client directives...?[/quote]That's a good question that I cannot fully answer. I recall when I did my initial research into doing this, this was one of the only setups I could get working. Could I trouble you for a short example of what you're talking about? Regards, -R.

maikat/janjust, Thanks for the responses, however, as it turns out, this had little to do with OpenVPN, and more with networking constructs, which was a mistake on my part. To accomplish what I wanted, proxy_arp needed to be enabled on both sides, on the LAN interfaces via [i]sysctl[/i], as well as not utilizing any NAT masquerading on the tunnel or the LAN interfaces. A simple example of proxy_arp/no NAT masquerade is client 172.31.[b][u]0[/u][/b].5 SSHes across the OpenVPN link to 172.31.[b][u]1[/u][/b].10, logs in and issues a [i]who[/i], which shows them logged in from 172.31.[b][u]0.5[/u][/b], vs 172.31.[b][u]1.1[/u][/b] (the OpenVPN gateway on the 172.31.1.0/24 network), when proxy_arp is not employed and NAT masquerade is in play on the tunnel and LAN devices. TL;DR, use proxy_arp, and no NAT masquerade if you want all the hosts to appear as if they're all on the same wire.

Site-to-Site Tunnel/IP masquerade question.

sinkr

Hello,

Long time OpenVPN administrator, first time poster here.

I have been employing for quite some time, at numerous sites, a site-to-site VPN using layer 3 tunnelling via TUN (not TAP) devices.

My configurations typically look like this:

side a  (LAN: 172.16.0.1)     < ------------- >          side b (LAN: 172.16.1.1)
172.16.0.0/24          172.31.0.1         172.16.0.2        172.16.1.0/24
                   side a tunnel IP     side b tunnel IP

Everything works both ways just fine, however, one annoying side effect of doing it this way is, if someone on side a communicates with a server on side b, the IP address that side b machine sees is side b's OpenVPN server LAN address, instead of the side a originating IP address.

So, for instance if a machine on side a with an IP of 172.16.0.5 talks to a machine on side b who's IP address is 172.16.1.10, the logs, network traffic, etc. don't reflect that it's 172.16.0.5; instead the LAN address of side b is what the client on that network sees (172.16.1.1).

So, the (sophomoric) question to be asked is, can we not show the gateway IP, but the real client IP's address? Because the tunnels are symmetric, both sides can communicate, such that any machines on 172.16.1.0/24 can directly access machines on 172.16.0.0/24, and vice-versa.

side a config:

port 1194
proto tcp-server
dev tun0
ca /etc/openvpn/CA/keys/ca.crt
cert /etc/openvpn/CA/keys/sidea.cert
key /etc/openvpn/CA/keys/sidea.key
dh /etc/openvpn/CA/keys/dh2048.pem
remote public.ip.of.side.b 1194
ifconfig 172.31.0.1 172.31.0.2
route 172.16.1.0 255.255.255.0 172.31.0.2
up /etc/openvpn/set-up-nat-and-routing.sh
tls-server
persist-key
persist-tun
cipher BF-CBC
verb 5
comp-lzo
float

side b config

port 1194
proto tcp-client
dev tun0
ca /etc/openvpn/CA/keys/ca.crt
cert /etc/openvpn/CA/keys/sideb.crt
key /etc/openvpn/CA/keys/sideb.key
dh /etc/openvpn/CA/keys/dh2048.pem
remote side.a.public.ip.address 1194
ifconfig 172.31.0.2 172.31.0.1
route 172.16.0.0 255.255.255.0 172.31.0.1
up /etc/openvpn/set-up-nat-and-routing.sh
tls-client
persist-key
persist-tun
cipher BF-CBC
verb 5
comp-lzo
float

Beyond this config, the systems are configured to do ipv4 forwarding, and the appropriate iptables-based forwarding. I have tried playing with the values of iptables -t nat -A POSTROUTING -o $INTERFACE -j MASQUERADE to not much avail (where $INTERFACE is the appropriate LAN interface).

Any suggestions would be appreciated--this really isn't a problem, as much as an annoyance of gap in knowledge.

maikcat

hi there,

So, for instance if a machine on side a with an IP of 172.16.0.5 talks to a machine on side b who's IP address is 172.16.1.10, the logs, network traffic, etc. don't reflect that it's 172.16.0.5; instead the LAN address of side b is what the client on that network sees (172.16.1.1).

as long as you use NAT

up /etc/openvpn/set-up-nat-and-routing.sh

its perfectly normal....

you can try remove the NAT and try to see if it works...

why dont you use the server & client directives...?

Michael.

sinkr

Hi Michael,

Thanks for the response.

I (re)tried your suggestion and turned NAT off via:

iptables -t nat -X
iptabels -t nat -F

and no traffic was passed.

I selectively started adding NAT back to the tunnel, LAN, and WAN (public/external) interfaces; I have 3 NAT rules in the /etc/openvpn/set-up-nat-and-routing.sh script that look like so:

iptables -t nat -A POSTROUTING -o tun+ -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Realistically, the only one that seems to make a difference (after clearing out the NAT rules) is:

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

...which yields the behavior I initially describe.

why dont you use the server & client directives...?

That's a good question that I cannot fully answer. I recall when I did my initial research into doing this, this was one of the only setups I could get working. Could I trouble you for a short example of what you're talking about?

Regards,

-R.

maikcat

did you enabled ip forwarding on *both* server/client?

you can use the server directive along with ccd files to
create lan-to-lan connectivity for multiple networks (they should use different network ranges)
also taking advantage that multiple clients share the same openvpn server service (and its single port).

if you need specific help (configs) let me know...

cheers,

ps: WITHOUT nat 😉

Michael.

janjust

As maikcat said, IP forwarding needs to be enabled on both ends; also, the networks on both sides need to be aware of each other, i.e. 172.16.1.0/24 needs to know that 172.16.0.0/24 can be found via the LAN IP of the tunnel (tunel IP=172.31.0.1) and vice versa: 172.16.0.0/24 needs to know that 172.16.1.0/24 is behind the LAN IP of that tunnel side.

when creatnig site-to-site VPNs it is often easier to NOT use client/server mode, as you don't have to bother with client-config-dir files and the likes - routing "just works".

sinkr

maikat/janjust,

Thanks for the responses, however, as it turns out, this had little to do with OpenVPN, and more with networking constructs, which was a mistake on my part.

To accomplish what I wanted, proxy_arp needed to be enabled on both sides, on the LAN interfaces via sysctl, as well as not utilizing any NAT masquerading on the tunnel or the LAN interfaces.

A simple example of proxy_arp/no NAT masquerade is client 172.31.0.5 SSHes across the OpenVPN link to 172.31.1.10, logs in and issues a who, which shows them logged in from 172.31.0.5, vs 172.31.1.1 (the OpenVPN gateway on the 172.31.1.0/24 network), when proxy_arp is not employed and NAT masquerade is in play on the tunnel and LAN devices.

TL;DR, use proxy_arp, and no NAT masquerade if you want all the hosts to appear as if they're all on the same wire.