root@p10:/proc/net# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
OVH Public Cloud Server, on OpenStack
Hello everyone,
I have weird behaviors with my iptables/NAT/16.04 installation.
OpenVPN is set up to receive connections and works properly. For some historical reasons, the VPN packets have to be egressed and translated on the WAN public interface ens33 (and use its address as source).
But the behavior of the Masquerade is not consistent.
For example, I enable the Masquerade, but it won't work right away. After few minutes (variable), it will start working. Then I remove the Masquerade, and it keeps working, for few minutes or maybe more.
All of this makes it hard for me to diagnose and implement further features (target goals is 2 VPNs NATed on 2 different public IP addresses)).
I really don't understand what's going on. If someone has a clue, please help!
Here's the detail :
Interfaces
ens3 Link encap:Ethernet HWaddr
inet addr:54.38.X.X
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.99.0.1 P-t-P:10.99.0.2 Mask:255.255.255.255
Filters
root@p10:/proc/net# iptables -L -vnx
Chain INPUT (policy DROP 53737 packets, 2988971 bytes)
pkts bytes target prot opt in out source destination
6120 612989 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:587
(...)
Chain FORWARD (policy ACCEPT 433 packets, 39648 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 10153 packets, 1034888 bytes)
pkts bytes target prot opt in out source destination
Masquerade
root@p10:/proc/net# iptables -t nat -L -vnx
Chain PREROUTING (policy ACCEPT 8367 packets, 465763 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 OUTPUT (policy ACCEPT 2 packets, 152 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
4 272 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0
Forward
root@p10:/proc/net# sysctl -a | grep "\.forwarding" | grep ipv4
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.ens3.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.tun0.forwarding = 1
Client
On my Windows VPN client, routes are pushed, for example to send packet to a test address 194.51.3.65 via the VPN :
Route print
194.51.3.65 255.255.255.255 10.99.5.118 10.99.5.117 291
C:\Windows\system32>ping 194.51.3.65
Envoi d’une requête 'Ping' 194.51.3.65 avec 32 octets de données :
Réponse de 194.51.3.65 : octets=32 temps=26 ms TTL=48
Statistiques Ping pour 194.51.3.65:
Paquets : envoyés = 1, reçus = 1, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 26ms, Maximum = 26ms, Moyenne = 26ms
Ctrl+C
^C
C:\Windows\system32>tracert -d 194.51.3.65
Détermination de l’itinéraire vers 194.51.3.65 avec un maximum de 30 sauts.
1 16 ms 15 ms 25 ms 10.99.0.1
2 19 ms 20 ms 17 ms 54.38.X.X
3 18 ms 21 ms 17 ms 158.69.61.222
4 61 ms 78 ms 15 ms 51.255.245.126
5 14 ms 16 ms 35 ms 10.97.155.39
As you can see, the test ping packets are sent via the VPN and work well.
Now the strange behavior I have is this one:
either I remove the Masquerade, but the pings keep working
or I remove the Masquerade and the pings stop working, but when I re-enable the Masquerade, they don't work anywore. Sometimes I'll have to wait 10 seconds, sometimes 5 minutes.
Other behaviors
Also, I have other weird things :
I can see conntracks :
root@p10:/proc/net# conntrack -L (...) conntrack v1.4.3 (conntrack-tools): 3 flow entries have been shown.
But I cannot see NAT sessions :
root@p10:/proc/net# netstat-nat Could not read info about connections from the kernel, make sure netfilter is enabled in kernel or by modules. root@p10:/proc/net#
0 Answers