OpenVPN not able to connect to public IP interface
I have 2 sites that used to be linked via OpenVPN. For some reason it stopped working.
General setups: Server OS: CentOS 7 OpenVPN v2.4.9 EasyRSA v.3.0.7 Edge firewall and VPN server is the same box. Using firewalld. IPTables is not running on either machine. Firewall settings: Quote:
Quote:
Quote:
I have also asked my ISP whether they are actively filtering OpenVPN, to which they have answered in the negative. Any help / advice would be greatly appreciated. |
Quote:
active zone is public and target shows DROP -> a source zone with the target DROP would drop all packets, even if they were whitelisted, first, change target to default. TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) TLS Error: TLS handshake failed -> this message means firewall blocking conn |
Quote:
Code:
--local host |
Quote:
|
Quote:
Also, if you're running through any sort of network device/firewall (network topology things), you may have to NAT UDP on your openVPN port to the server THERE as well. |
Quote:
client.conf Quote:
Quote:
Quote:
|
You could observe the packet filter stats on the server soon after attempting to connect from the client....
Code:
sudo iptables -vnL Code:
sudo watch iptables -vnL That might show where the traffic is blocked (unintentionally). |
Quote:
|
Firewalld is just a userspace utility. The resulting applied filter rules are run kernelspace. The iptables command allows us to examine these.
|
Quote:
|
Not quite sure what I should be looking for. Below is the result of
Code:
iptables -vnL I've removed entries that have no entries in them. But you might say I'm a total iptables noob... Quote:
|
The output shows the tun0 interface present and the following suggests two rules for the same service
Code:
Chain IN_public_allow (1 references) |
Quote:
I did add the 2nd rule (1194/udp). I should probably remove it. but does this indicate why my client can't connect? |
It might be useful to show us
Code:
iptables -S Just in case the following is helpful... https://forums.openvpn.net/viewtopic.php?t=14286#p35352 |
Results of iptables -S
Quote:
|
That looks as expected to me.
NAT rules? Code:
sudo iptables -t nat -L -n -v |
Quote:
Quote:
|
I'm struggling to see where the openvpn-related packets are being dropped. This command will show any differences dynamically...
Code:
sudo watch -d iptables -vnL Some other similar approaches (including sorting and filtering) to help identify rules being triggered by changes to packet counters.... https://unix.stackexchange.com/quest...pping-a-packet Some careful observation when attempting to connect to the server should help you identify the issue. You may also want to ensure little/no other services are running to minimise other kinds of traffic hitting/leaving the server. |
Quote:
On a semi-related note, how can I simplify my rules? Basically my setup is just a CentOS 7 box with 2 NICs (edge firewall) running squid and firewalld. Nothing special about it. |
Quote:
Quote:
|
Quote:
|
Hi all, I know it's been awhile. Took our ISP more than a month to migrate our account to a corporate account which allowed more than one public IP address.
New settings as follows. I have migrated the firewall to iptables. From the iptables output, the packets are hitting the interface and are being allowed to enter. But somehow something is getting messed up upon authentication.. result of iptables -nvL (includes the nat table): Chain INPUT (policy ACCEPT 1228 packets, 226K bytes) pkts bytes target prot opt in out source destination 2259 145K ACCEPT tcp -- * * 192.168.20.0/24 0.0.0.0/0 tcp dpt:22 state NEW,ESTABLISHED /* Allow ssh */ 0 0 ACCEPT icmp -- * * 192.168.20.0/24 0.0.0.0/0 icmptype 8 /* Allow pings from the inside */ 0 0 ACCEPT icmp -- enp4s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 0 0 0 ACCEPT tcp -- * * 192.168.20.0/24 0.0.0.0/0 tcp dpt:3128 state NEW,ESTABLISHED /* Allow Squid */ 4 200 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 /* Allow everything from loopback */ 0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0 /* Trust the tunnel interfaces */ 68 3856 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 /* Allow openvpn traffic */ 199 23276 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 DROP icmp -- enp4s0 * 0.0.0.0/0 0.0.0.0/0 icmptype 8 /* Drop pings from the outside */ 351 62722 DROP all -- enp4s0 * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0 6 405 ACCEPT all -- * enp4s0 0.0.0.0/0 0.0.0.0/0 state NEW 12 1286 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED Chain OUTPUT (policy ACCEPT 80 packets, 4128 bytes) pkts bytes target prot opt in out source destination 1598 322K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:22 state ESTABLISHED 0 0 ACCEPT icmp -- * enp4s0 0.0.0.0/0 0.0.0.0/0 icmptype 8 51 3665 ACCEPT all -- * enp4s0 0.0.0.0/0 0.0.0.0/0 state NEW 12 1570 ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0 Chain PREROUTING (policy ACCEPT 1564 packets, 333K bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 578 packets, 138K bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 42 packets, 2810 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 12 packets, 636 bytes) pkts bytes target prot opt in out source destination 36 2579 MASQUERADE all -- * enp4s0 0.0.0.0/0 0.0.0.0/0 server.conf file: port 1194 float proto udp dev tun ca server/keys/ca.crt cert server/keys/server.crt key server/keys/server.key dh server/keys/dh4096.pem topology subnet server 10.9.0.0 255.255.255.0 push "route 192.168.20.0 255.255.255.0" keepalive 10 120 cipher AES-256-CBC comp-lzo user nobody group nobody persist-key persist-tun status openvpn-status.log log-append openvpn.log ifconfig-pool-persist ipp.txt verb 4 explicit-exit-notify 1 client.conf: client dev tun proto udp remote ... 1194 float resolv-retry infinite nobind user nobody group nobody persist-key persist-tun ca client/ca.crt cert ... key ... cipher AES-256-CBC comp-lzo verb 4 openvpn.log snippet: Wed Nov 11 12:55:35 2020 us=354766 210.4.125.138:38147 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server' Wed Nov 11 12:55:35 2020 us=354802 210.4.125.138:38147 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client' Wed Nov 11 12:55:35 2020 us=354883 210.4.125.138:38147 TLS: Initial packet from [AF_INET]210.4.125.138:38147, sid=697de220 8ce4f40e Wed Nov 11 12:55:35 2020 us=355031 210.4.125.138:38147 TLS Error: reading acknowledgement record from packet Wed Nov 11 12:55:37 2020 us=671070 210.4.125.138:38147 TLS Error: reading acknowledgement record from packet Wed Nov 11 12:55:41 2020 us=144338 210.4.125.138:38147 TLS Error: reading acknowledgement record from packet Wed Nov 11 12:55:49 2020 us=148177 210.4.125.138:38147 TLS Error: reading acknowledgement record from packet Wed Nov 11 12:56:05 2020 us=922602 210.4.125.138:38147 TLS Error: reading acknowledgement record from packet Wed Nov 11 12:56:34 2020 us=641114 MULTI: multi_create_instance called Wed Nov 11 12:56:34 2020 us=641301 192.168.20.151:59344 Re-using SSL/TLS context Wed Nov 11 12:56:34 2020 us=641366 192.168.20.151:59344 LZO compression initializing Wed Nov 11 12:56:34 2020 us=641483 192.168.20.151:59344 Control Channel MTU parms [ L:1622 D:1212 EF:38 EB:0 ET:0 EL:3 ] Wed Nov 11 12:56:34 2020 us=641528 192.168.20.151:59344 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ] Wed Nov 11 12:56:34 2020 us=641608 192.168.20.151:59344 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server' Wed Nov 11 12:56:34 2020 us=641645 192.168.20.151:59344 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client' Wed Nov 11 12:56:34 2020 us=641755 192.168.20.151:59344 TLS: Initial packet from [AF_INET]192.168.20.151:59344, sid=77be5316 73e82d0a Wed Nov 11 12:56:35 2020 us=867464 210.4.125.138:38147 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Wed Nov 11 12:56:35 2020 us=867536 210.4.125.138:38147 TLS Error: TLS handshake failed Wed Nov 11 12:56:35 2020 us=867652 210.4.125.138:38147 SIGUSR1[soft,tls-error] received, client-instance restarting |
The TLS error caught my attention...
Code:
TLS Error: reading acknowledgement record from packet http://www.f15ijp.com/2010/08/openvp...d-from-packet/ |
Quote:
|
All times are GMT -5. The time now is 04:25 AM. |