Production OpenVPN config and routing I can't figure out

[peterwood]

I inherited a working OpenVPN setup that I'm trying to rebuild/replicate and I just can't figure it out.

Clients establish VPN connection with the OpenVPN server and then systems in the OpenVPN server local network can access (ping) the clients.

In the working setup the OpenVPN server will change the source IP to the tun0 IP. The client will receive the request packet and reply back on the tun0 interface.

I copied all config files, setup IP forwarding and still the ECHO Request packet arrives to the client with source IP the LAN IP of the Local Server instead of the OpenVPN tun0 IP. The client is trying to reply but it routes the packet to it's default GW which is not the tun0 interface and of course the reply packet never arrives.

[OpenVPN Client] <=tunnel=> [OpenVPN Server] <-lan-> [Local Server]

- OpenVPN_Server:

Code: Select all

[root@openvpn_server ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 56:6f:d6:a6:00:1d brd ff:ff:ff:ff:ff:ff
    inet 10.12.0.56/20 brd 10.12.15.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::546f:d6ff:fea6:1d/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 10.138.0.1 peer 10.138.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever

[root@openvpn_server ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.12.0.1       0.0.0.0         UG    100    0        0 ens3
10.12.0.0       0.0.0.0         255.255.240.0   U     100    0        0 ens3
10.138.0.0      10.138.0.2      255.255.0.0     UG    0      0        0 tun0
10.138.0.2      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
[root@openvpn_server ~]#

- LocalServer :

Code: Select all

[root@local_server ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 56:6f:bb:74:00:c2 brd ff:ff:ff:ff:ff:ff
    inet 10.12.1.254/20 brd 10.12.15.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::546f:bbff:fe74:c2/64 scope link
       valid_lft forever preferred_lft forever


[root@local_server ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.12.0.1       0.0.0.0         UG    100    0        0 eth0
10.12.0.0       0.0.0.0         255.255.240.0   U     100    0        0 eth0
10.138.0.0      10.12.0.56      255.255.0.0     UG    0      0        0 eth0
[root@pbb-centos7 ~]#

- OpenVN_Client:

Code: Select all

[root@openvpn_client ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:2d:e8:f0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.28.13/24 brd 192.168.28.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe2d:e8f0/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 10.138.138.134 peer 10.138.138.133/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::33fe:d866:7062:df08/64 scope link flags 800
       valid_lft forever preferred_lft forever


[root@openvpn_client ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.28.1    0.0.0.0         UG    0      0        0 eth0
10.138.0.1      10.138.138.133  255.255.255.255 UGH   0      0        0 tun0
10.138.138.133  0.0.0.0         255.255.255.255 UH    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
192.168.28.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
[root@openvpn_client ~]#

When LocalServer sends ping request to the OpenVPN_Client, the OpenVPN_Server changes the source IP to the tun0 IP:

Code: Select all

17:39:50.162504  In 56:6f:bb:74:00:c2 ethertype IPv4 (0x0800), length 100: 10.12.1.254 > 10.138.138.134: ICMP echo request, id 4459, seq 1, length 64
17:39:50.162566 Out ethertype IPv4 (0x0800), length 100: 10.138.0.1 > 10.138.138.134: ICMP echo request, id 4459, seq 1, length 64

Notice how the source IP in the Out packet is now 10.138.0.1 which is tun0 IP. How do I do that?

The client receives the packet and the reply goes back through the tunnel to 10.138.0.1:

Code: Select all

17:17:14.544567  In ethertype IPv4 (0x0800), length 100: 10.138.0.1 > 10.138.138.134: ICMP echo request, id 4459, seq 1, length 64
17:17:14.544663 Out ethertype IPv4 (0x0800), length 100: 10.138.138.134 > 10.138.0.1: ICMP echo reply, id 4459, seq 1, length 64

In my setup the OpenVPN server keeps the same source IP when it forwards the packet:

Code: Select all

19:29:45.567260  In da:d6:2e:ce:10:0e ethertype IPv4 (0x0800), length 100: 10.12.1.254 > 10.138.138.134: ICMP echo request, id 4303, seq 1, length 64
19:29:45.567385 Out ethertype IPv4 (0x0800), length 100: 10.12.1.254 > 10.138.138.134: ICMP echo request, id 4303, seq 1, length 64

The OpenVPN client receives it with source IP of 10.12.1.254 and the reply goes to the default gateway of the client and it gets lost.

On the client I can add a route

Code: Select all

route add -net 10.138.0.0/16 10.138.138.133

and traffic will start flowing but business restrictions prevent this. We don't want to add routes to the client systems and make our internal network accessible.

How do I configure the OpenVPN server to change the source IP like in the example above?

Any help is appreciated.

Thank you,
-- Peter

View OriginalOpenVPN_Server Config

mode server
local 10.12.0.56
proto udp
port 1194
dev tun
server 10.138.0.0 255.255.0.0
ifconfig-pool-persist ipp.txt
keepalive 10 60
comp-lzo
user nobody
group nobody
persist-key
persist-tun
plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so svx-openvpn-auth
client-cert-not-required
username-as-common-name
tls-auth ta.key 0
dh dh1024.pem
ca /etc/pki/tls/certs/ca.crt
cert /etc/pki/tls/certs/openvpn_server.crt
key /etc/pki/tls/private/openvpn_server.key
management 127.0.0.1 12358
verb 3

View OriginalOpenVPN_Client

client
remote OpenVPN_Server.company.com
proto udp
port 1194
explicit-exit-notify
dev tun
ns-cert-type server
reneg-sec 86400
auth-user-pass /tmp/openvpn-auth.txt
auth-retry none
comp-lzo
hand-window 10
ca /etc/pki/tls/certs/ca.crt
tls-auth /etc/openvpn/ta.key 1
verb 1

[TinCanTech]

This is your job and you need professional help.

You can contact me: tincantech <at> protonmail dot com -- Fees will apply.

[peterwood]

I was missing masquerading on the tun0 interface on the OpenVPN_Server. I enabled it on the LAN interface but missed it on the tun0 interface. I guess I ran firewall-cmd without --permanent and after reboot or reload it got reverted back to the default setting.

Anyway, it turns out the problem has nothing to do with OpenVPN nor with routing. Sorry for the spam.

Thank you,
-- Peter

[TinCanTech]

turns out the problem has nothing to do with OpenVPN

We know -- thanks