LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   OpenVPN not able to connect to public IP interface (https://www.linuxquestions.org/questions/linux-security-4/openvpn-not-able-to-connect-to-public-ip-interface-4175679299/)

THawk254 07-24-2020 09:58 AM

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:

public (active)
target: DROP
icmp-block-inversion: yes
interfaces: enp2s0
sources:
services: openvpn
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
While trying to connect to the public interface, client side has been getting:

Quote:

UDP WRITE [86] to [AF_INET](public IP Address):1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0
UDP WRITE [86] to [AF_INET](public IP Address):1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
UDP WRITE [86] to [AF_INET](public IP Address):1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #3 ] [ ] pid=0 DATA len=0
UDP WRITE [86] to [AF_INET](public IP Address):1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #4 ] [ ] pid=0 DATA len=0
UDP WRITE [86] to [AF_INET](public IP Address):1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #5 ] [ ] pid=0 DATA len=0
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
I've done a tcpdump of my public facing interface
Quote:

tcpdump -vni enp2s0 port 1194 and udp
Nothing shows, which tells me that the packets aren't even hitting the interface.

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.

marliyev 07-24-2020 11:47 AM

Quote:

Originally Posted by THawk254 (Post 6148842)
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:


While trying to connect to the public interface, client side has been getting:


I've done a tcpdump of my public facing interface


Nothing shows, which tells me that the packets aren't even hitting the interface.

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.




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

TB0ne 07-24-2020 06:08 PM

Quote:

Originally Posted by THawk254 (Post 6148842)
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:
Code:

public (active)
target: DROP
icmp-block-inversion: yes
interfaces: enp2s0
sources:
services: openvpn
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:

While trying to connect to the public interface, client side has been getting:
Code:

UDP WRITE [86] to [AF_INET](public IP Address):1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0
UDP WRITE [86] to [AF_INET](public IP Address):1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
UDP WRITE [86] to [AF_INET](public IP Address):1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #3 ] [ ] pid=0 DATA len=0
UDP WRITE [86] to [AF_INET](public IP Address):1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #4 ] [ ] pid=0 DATA len=0
UDP WRITE [86] to [AF_INET](public IP Address):1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #5 ] [ ] pid=0 DATA len=0
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed

I've done a tcpdump of my public facing interface
Code:

tcpdump -vni enp2s0 port 1194 and udp
Nothing shows, which tells me that the packets aren't even hitting the interface. I have also asked my ISP whether they are actively filtering OpenVPN, to which they have answered in the negative.

If you're *SURE* that your firewall isn't blocking VPN on UDP 1194 (which would be the first thing to check), based on the error message it looks like the traffic is either blocked or misdirected. Do you have a firewall on your client?? Those would be first things to check is firewall on both sides. Past that, check into the "local" directive for your openVPN server config:
Code:

--local host
Local host name or IP address. If specified, OpenVPN will bind to this address only. If unspecified, OpenVPN will bind to all interfaces.

Sometimes specifying that will get things going out the right interface. Post your openvpn.conf file (sanitized of identifying info, ideally) and we can take a further look.

THawk254 07-25-2020 03:44 AM

Quote:

Originally Posted by TB0ne (Post 6149019)
If you're *SURE* that your firewall isn't blocking VPN on UDP 1194 (which would be the first thing to check), based on the error message it looks like the traffic is either blocked or misdirected. Do you have a firewall on your client?? Those would be first things to check is firewall on both sides. Past that, check into the "local" directive for your openVPN server config:
Code:

--local host
Local host name or IP address. If specified, OpenVPN will bind to this address only. If unspecified, OpenVPN will bind to all interfaces.

Sometimes specifying that will get things going out the right interface. Post your openvpn.conf file (sanitized of identifying info, ideally) and we can take a further look.

Both sides are CentOS boxes with the same firewalld settings. First thing I'm going to try on Monday is to set target to default of the default zone.

TB0ne 07-25-2020 09:23 AM

Quote:

Originally Posted by THawk254 (Post 6149117)
Both sides are CentOS boxes with the same firewalld settings. First thing I'm going to try on Monday is to set target to default of the default zone.

Yes, that error is typically because traffic isn't getting through (firewall) or is getting misdirected (openVPN listening on all interfaces and not routing back correctly). The 'quick-dirty-not-too-good' way to test is to disable your firewalld on both sides for a few minutes and see if things work. That narrows down things being blocked vs. server config problem.

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.

THawk254 07-27-2020 01:27 AM

Quote:

Originally Posted by TB0ne (Post 6149204)
Yes, that error is typically because traffic isn't getting through (firewall) or is getting misdirected (openVPN listening on all interfaces and not routing back correctly). The 'quick-dirty-not-too-good' way to test is to disable your firewalld on both sides for a few minutes and see if things work. That narrows down things being blocked vs. server config problem.

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.

I shut down firewalld and lo and behold, it worked! But since I can't just shut down an edge firewall, how can I determine what's blocking my UDP packets. I also changed the default target of my active zone (Public) to default, as per marilyev's suggestion but I still have no packets hitting the interface.

client.conf

Quote:

client
dev tun
proto udp
remote ...
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
tls-client
ca ...
cert ...
key ...
tls-crypt ...
tls-cipher TLS-ECDHE-RSA-WITH-AES-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
remote-cert-tls server
cipher AES-256-CBC
auth SHA512
auth-nocache
;comp-lzo
verb 6
server.conf

Quote:

local ...
port 1194
proto udp
dev tun
ca easyrsa/pki/ca.crt
cert easyrsa/pki/issued/server.crt
key easyrsa/pki/private/server.key
dh easyrsa/pki/dh.pem
;tls-auth ... 0
tls-crypt ...
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.20.0 255.255.255.0"
keepalive 10 120
cipher AES-256-CBC
auth SHA512
;comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 4
explicit-exit-notify 1
Current firewalld configuration (though I'm going to close the 1194/tcp port since I'm not using it.)

Quote:

public (active)
target: default
icmp-block-inversion: yes
interfaces: enp2s0
sources:
services: openvpn
ports: 1194/tcp 1194/udp
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:

ferrari 07-27-2020 04:24 AM

You could observe the packet filter stats on the server soon after attempting to connect from the client....
Code:

sudo iptables -vnL
Or run it live in a terminal before connecting
Code:

sudo watch iptables -vnL
then connect and observe.

That might show where the traffic is blocked (unintentionally).

THawk254 07-27-2020 05:05 AM

Quote:

Originally Posted by ferrari (Post 6149717)
You could observe the packet filter stats on the server soon after attempting to connect from the client....
Code:

sudo iptables -vnL
Or run it live in a terminal before connecting
Code:

sudo watch iptables -vnL
then connect and observe.

That might show where the traffic is blocked (unintentionally).

will this run even if I don't have iptables running on the machine?

ferrari 07-27-2020 05:14 AM

Firewalld is just a userspace utility. The resulting applied filter rules are run kernelspace. The iptables command allows us to examine these.

THawk254 07-27-2020 06:04 AM

Quote:

Originally Posted by ferrari (Post 6149729)
Firewalld is just a userspace utility. The resulting applied filter rules are run kernelspace. The iptables command allows us to examine these.

Ok. I'll try that tomorrow morning.

THawk254 07-27-2020 11:51 PM

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:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
1795K 1773M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
2 120 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
65759 8563K INPUT_direct all -- * * 0.0.0.0/0 0.0.0.0/0
65759 8563K INPUT_ZONES all -- * * 0.0.0.0/0 0.0.0.0/0
830 41344 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
56938 8066K REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0
0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0
0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
14M 14G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
126K 20M FORWARD_direct all -- * * 0.0.0.0/0 0.0.0.0/0
126K 20M FORWARD_IN_ZONES all -- * * 0.0.0.0/0 0.0.0.0/0
126K 20M FORWARD_OUT_ZONES all -- * * 0.0.0.0/0 0.0.0.0/0
1171 50587 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 2490K packets, 1811M bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * virbr0 0.0.0.0/0 0.0.0.0/0 udp dpt:68
173 20729 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
2490K 1811M OUTPUT_direct all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD_IN_ZONES (1 references)
pkts bytes target prot opt in out source destination
126K 20M FWDI_internal all -- * * 192.168.20.0/24 0.0.0.0/0 [goto]
0 0 FWDI_trusted all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] match-set sshOK src
0 0 FWDI_public all -- enp2s0 * 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 FWDI_internal all -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 FWDI_trusted all -- tun0 * 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 FWDI_public all -- + * 0.0.0.0/0 0.0.0.0/0 [goto]

Chain FORWARD_OUT_ZONES (1 references)
pkts bytes target prot opt in out source destination
0 0 FWDO_internal all -- * * 0.0.0.0/0 192.168.20.0/24 [goto]
0 0 FWDO_trusted all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] match-set sshOK dst
126K 20M FWDO_public all -- * enp2s0 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 FWDO_internal all -- * enp3s0 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 FWDO_trusted all -- * tun0 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 FWDO_public all -- * + 0.0.0.0/0 0.0.0.0/0 [goto]

Chain FORWARD_direct (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- eth_int enp2s0 0.0.0.0/0 0.0.0.0/0

Chain FWDI_internal (2 references)
pkts bytes target prot opt in out source destination
126K 20M FWDI_internal_log all -- * * 0.0.0.0/0 0.0.0.0/0
126K 20M FWDI_internal_deny all -- * * 0.0.0.0/0 0.0.0.0/0
126K 20M FWDI_internal_allow all -- * * 0.0.0.0/0 0.0.0.0/0
2 384 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0

Chain FWDI_public (2 references)
pkts bytes target prot opt in out source destination
0 0 FWDI_public_log all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 FWDI_public_deny all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 FWDI_public_allow all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 REJECT icmp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain FWDI_trusted (2 references)
pkts bytes target prot opt in out source destination
0 0 FWDI_trusted_log all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 FWDI_trusted_deny all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 FWDI_trusted_allow all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FWDO_internal (2 references)
pkts bytes target prot opt in out source destination
0 0 FWDO_internal_log all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 FWDO_internal_deny all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 FWDO_internal_allow all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FWDO_public (2 references)
pkts bytes target prot opt in out source destination
126K 20M FWDO_public_log all -- * * 0.0.0.0/0 0.0.0.0/0
126K 20M FWDO_public_deny all -- * * 0.0.0.0/0 0.0.0.0/0
126K 20M FWDO_public_allow all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FWDO_public_allow (1 references)
pkts bytes target prot opt in out source destination
125K 20M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW,UNTRACKED
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW,UNTRACKED

Chain INPUT_ZONES (1 references)
pkts bytes target prot opt in out source destination
51747 7197K IN_internal all -- * * 192.168.20.0/24 0.0.0.0/0 [goto]
0 0 IN_trusted all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] match-set sshOK src
12684 1050K IN_public all -- enp2s0 * 0.0.0.0/0 0.0.0.0/0 [goto]
1328 315K IN_internal all -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 IN_trusted all -- tun0 * 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 IN_public all -- + * 0.0.0.0/0 0.0.0.0/0 [goto]

Chain IN_internal (2 references)
pkts bytes target prot opt in out source destination
53075 7512K IN_internal_log all -- * * 0.0.0.0/0 0.0.0.0/0
53075 7512K IN_internal_deny all -- * * 0.0.0.0/0 0.0.0.0/0
53075 7512K IN_internal_allow all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0

Chain IN_internal_allow (1 references)
pkts bytes target prot opt in out source destination
4 268 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ctstate NEW,UNTRACKED
0 0 ACCEPT udp -- * * 0.0.0.0/0 224.0.0.251 udp dpt:5353 ctstate NEW,UNTRACKED
7166 390K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3128 ctstate NEW,UNTRACKED

Chain IN_public (2 references)
pkts bytes target prot opt in out source destination
12684 1050K IN_public_log all -- * * 0.0.0.0/0 0.0.0.0/0
12684 1050K IN_public_deny all -- * * 0.0.0.0/0 0.0.0.0/0
12684 1050K IN_public_allow all -- * * 0.0.0.0/0 0.0.0.0/0
820 65216 REJECT icmp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain IN_public_allow (1 references)
pkts bytes target prot opt in out source destination
1 42 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 ctstate NEW,UNTRACKED
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 ctstate NEW,UNTRACKED

ferrari 07-28-2020 12:34 AM

The output shows the tun0 interface present and the following suggests two rules for the same service
Code:

Chain IN_public_allow (1 references)
pkts bytes target prot opt in out source destination
1 42 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 ctstate NEW,UNTRACKED
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 ctstate NEW,UNTRACKED

The second rule never gets matched due to the first and can be removed. I note from the firewald config output that you had 'openvpn' service defined as well as port 1194 UDP explicitly. Only the former is needed.

THawk254 07-28-2020 12:38 AM

Quote:

Originally Posted by ferrari (Post 6150081)
The output shows the tun0 interface present and the following suggests two rules for the same service
Code:

Chain IN_public_allow (1 references)
pkts bytes target prot opt in out source destination
1 42 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 ctstate NEW,UNTRACKED
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 ctstate NEW,UNTRACKED

The second rule never gets matched due to the first and can be removed. I note from the firewald config output that you had 'openvpn' service defined as well as port 1194 UDP explicitly. Only the former is needed.

tun0 should be present on the server as openvpn@server is running.
I did add the 2nd rule (1194/udp). I should probably remove it.

but does this indicate why my client can't connect?

ferrari 07-28-2020 01:00 AM

It might be useful to show us
Code:

iptables -S
I wonder if masquerading is the issue here?


Just in case the following is helpful...
https://forums.openvpn.net/viewtopic.php?t=14286#p35352

THawk254 07-28-2020 01:05 AM

Results of iptables -S

Quote:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N FORWARD_IN_ZONES
-N FORWARD_OUT_ZONES
-N FORWARD_direct
-N FWDI_internal
-N FWDI_internal_allow
-N FWDI_internal_deny
-N FWDI_internal_log
-N FWDI_public
-N FWDI_public_allow
-N FWDI_public_deny
-N FWDI_public_log
-N FWDI_trusted
-N FWDI_trusted_allow
-N FWDI_trusted_deny
-N FWDI_trusted_log
-N FWDO_internal
-N FWDO_internal_allow
-N FWDO_internal_deny
-N FWDO_internal_log
-N FWDO_public
-N FWDO_public_allow
-N FWDO_public_deny
-N FWDO_public_log
-N FWDO_trusted
-N FWDO_trusted_allow
-N FWDO_trusted_deny
-N FWDO_trusted_log
-N INPUT_ZONES
-N INPUT_direct
-N IN_internal
-N IN_internal_allow
-N IN_internal_deny
-N IN_internal_log
-N IN_public
-N IN_public_allow
-N IN_public_deny
-N IN_public_log
-N IN_trusted
-N IN_trusted_allow
-N IN_trusted_deny
-N IN_trusted_log
-N OUTPUT_direct
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_direct
-A INPUT -j INPUT_ZONES
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -j FORWARD_direct
-A FORWARD -j FORWARD_IN_ZONES
-A FORWARD -j FORWARD_OUT_ZONES
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -j OUTPUT_direct
-A FORWARD_IN_ZONES -s 192.168.20.0/24 -g FWDI_internal
-A FORWARD_IN_ZONES -m set --match-set sshOK src -g FWDI_trusted
-A FORWARD_IN_ZONES -i enp2s0 -g FWDI_public
-A FORWARD_IN_ZONES -i enp3s0 -g FWDI_internal
-A FORWARD_IN_ZONES -i tun0 -g FWDI_trusted
-A FORWARD_IN_ZONES -g FWDI_public
-A FORWARD_OUT_ZONES -d 192.168.20.0/24 -g FWDO_internal
-A FORWARD_OUT_ZONES -m set --match-set sshOK dst -g FWDO_trusted
-A FORWARD_OUT_ZONES -o enp2s0 -g FWDO_public
-A FORWARD_OUT_ZONES -o enp3s0 -g FWDO_internal
-A FORWARD_OUT_ZONES -o tun0 -g FWDO_trusted
-A FORWARD_OUT_ZONES -g FWDO_public
-A FORWARD_direct -i eth_int -o enp2s0 -j ACCEPT
-A FWDI_internal -j FWDI_internal_log
-A FWDI_internal -j FWDI_internal_deny
-A FWDI_internal -j FWDI_internal_allow
-A FWDI_internal -p icmp -j ACCEPT
-A FWDI_public -j FWDI_public_log
-A FWDI_public -j FWDI_public_deny
-A FWDI_public -j FWDI_public_allow
-A FWDI_public -p icmp -j REJECT --reject-with icmp-host-prohibited
-A FWDI_trusted -j FWDI_trusted_log
-A FWDI_trusted -j FWDI_trusted_deny
-A FWDI_trusted -j FWDI_trusted_allow
-A FWDI_trusted -j ACCEPT
-A FWDO_internal -j FWDO_internal_log
-A FWDO_internal -j FWDO_internal_deny
-A FWDO_internal -j FWDO_internal_allow
-A FWDO_public -j FWDO_public_log
-A FWDO_public -j FWDO_public_deny
-A FWDO_public -j FWDO_public_allow
-A FWDO_public_allow -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A FWDO_public_allow -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A FWDO_trusted -j FWDO_trusted_log
-A FWDO_trusted -j FWDO_trusted_deny
-A FWDO_trusted -j FWDO_trusted_allow
-A FWDO_trusted -j ACCEPT
-A INPUT_ZONES -s 192.168.20.0/24 -g IN_internal
-A INPUT_ZONES -m set --match-set sshOK src -g IN_trusted
-A INPUT_ZONES -i enp2s0 -g IN_public
-A INPUT_ZONES -i enp3s0 -g IN_internal
-A INPUT_ZONES -i tun0 -g IN_trusted
-A INPUT_ZONES -g IN_public
-A IN_internal -j IN_internal_log
-A IN_internal -j IN_internal_deny
-A IN_internal -j IN_internal_allow
-A IN_internal -p icmp -j ACCEPT
-A IN_internal_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_internal_allow -d 224.0.0.251/32 -p udp -m udp --dport 5353 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_internal_allow -p tcp -m tcp --dport 3128 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_public -j IN_public_log
-A IN_public -j IN_public_deny
-A IN_public -j IN_public_allow
-A IN_public -p icmp -j REJECT --reject-with icmp-host-prohibited
-A IN_public_allow -p udp -m udp --dport 1194 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p udp -m udp --dport 1194 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_trusted -j IN_trusted_log
-A IN_trusted -j IN_trusted_deny
-A IN_trusted -j IN_trusted_allow
-A IN_trusted -j ACCEPT
-A IN_trusted_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT

ferrari 07-28-2020 01:40 AM

That looks as expected to me.

NAT rules?
Code:

sudo iptables -t nat -L -n -v

THawk254 07-28-2020 01:48 AM

Quote:

Originally Posted by ferrari (Post 6150097)
That looks as expected to me.

NAT rules?
Code:

sudo iptables -t nat -L -n -v

Results below.

Quote:

Chain PREROUTING (policy ACCEPT 32484 packets, 4742K bytes)
pkts bytes target prot opt in out source destination
32486 4742K PREROUTING_direct all -- * * 0.0.0.0/0 0.0.0.0/0
32486 4742K PREROUTING_ZONES all -- * * 0.0.0.0/0 0.0.0.0/0

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

Chain OUTPUT (policy ACCEPT 1246 packets, 97226 bytes)
pkts bytes target prot opt in out source destination
1246 97226 OUTPUT_direct all -- * * 0.0.0.0/0 0.0.0.0/0

Chain POSTROUTING (policy ACCEPT 28 packets, 23386 bytes)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 192.168.122.0/24 224.0.0.0/24
0 0 RETURN all -- * * 192.168.122.0/24 255.255.255.255
0 0 MASQUERADE tcp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
0 0 MASQUERADE udp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
0 0 MASQUERADE all -- * * 192.168.122.0/24 !192.168.122.0/24
11731 1629K POSTROUTING_direct all -- * * 0.0.0.0/0 0.0.0.0/0
28 23386 POSTROUTING_ZONES all -- * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT_direct (1 references)
pkts bytes target prot opt in out source destination

Chain POSTROUTING_ZONES (1 references)
pkts bytes target prot opt in out source destination
28 23386 POST_internal all -- * * 0.0.0.0/0 192.168.20.0/24 [goto]
0 0 POST_trusted all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] match-set sshOK dst
0 0 POST_public all -- * enp2s0 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 POST_internal all -- * enp3s0 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 POST_trusted all -- * tun0 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 POST_public all -- * + 0.0.0.0/0 0.0.0.0/0 [goto]

Chain POSTROUTING_direct (1 references)
pkts bytes target prot opt in out source destination
11703 1605K MASQUERADE all -- * enp2s0 0.0.0.0/0 0.0.0.0/0

Chain POST_internal (2 references)
pkts bytes target prot opt in out source destination
28 23386 POST_internal_log all -- * * 0.0.0.0/0 0.0.0.0/0
28 23386 POST_internal_deny all -- * * 0.0.0.0/0 0.0.0.0/0
28 23386 POST_internal_allow all -- * * 0.0.0.0/0 0.0.0.0/0

Chain POST_internal_allow (1 references)
pkts bytes target prot opt in out source destination

Chain POST_internal_deny (1 references)
pkts bytes target prot opt in out source destination

Chain POST_internal_log (1 references)
pkts bytes target prot opt in out source destination

Chain POST_public (2 references)
pkts bytes target prot opt in out source destination
0 0 POST_public_log all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 POST_public_deny all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 POST_public_allow all -- * * 0.0.0.0/0 0.0.0.0/0

Chain POST_public_allow (1 references)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * !lo 0.0.0.0/0 0.0.0.0/0
0 0 MASQUERADE all -- * !lo 0.0.0.0/0 0.0.0.0/0

Chain POST_public_deny (1 references)
pkts bytes target prot opt in out source destination

Chain POST_public_log (1 references)
pkts bytes target prot opt in out source destination

Chain POST_trusted (2 references)
pkts bytes target prot opt in out source destination
0 0 POST_trusted_log all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 POST_trusted_deny all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 POST_trusted_allow all -- * * 0.0.0.0/0 0.0.0.0/0

Chain POST_trusted_allow (1 references)
pkts bytes target prot opt in out source destination

Chain POST_trusted_deny (1 references)
pkts bytes target prot opt in out source destination

Chain POST_trusted_log (1 references)
pkts bytes target prot opt in out source destination

Chain PREROUTING_ZONES (1 references)
pkts bytes target prot opt in out source destination
31225 4525K PRE_internal all -- * * 192.168.20.0/24 0.0.0.0/0 [goto]
0 0 PRE_trusted all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] match-set sshOK src
775 117K PRE_public all -- enp2s0 * 0.0.0.0/0 0.0.0.0/0 [goto]
486 100K PRE_internal all -- enp3s0 * 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 PRE_trusted all -- tun0 * 0.0.0.0/0 0.0.0.0/0 [goto]
0 0 PRE_public all -- + * 0.0.0.0/0 0.0.0.0/0 [goto]

Chain PREROUTING_direct (1 references)
pkts bytes target prot opt in out source destination

Chain PRE_internal (2 references)
pkts bytes target prot opt in out source destination
31711 4625K PRE_internal_log all -- * * 0.0.0.0/0 0.0.0.0/0
31711 4625K PRE_internal_deny all -- * * 0.0.0.0/0 0.0.0.0/0
31711 4625K PRE_internal_allow all -- * * 0.0.0.0/0 0.0.0.0/0

Chain PRE_internal_allow (1 references)
pkts bytes target prot opt in out source destination

Chain PRE_internal_deny (1 references)
pkts bytes target prot opt in out source destination

Chain PRE_internal_log (1 references)
pkts bytes target prot opt in out source destination

Chain PRE_public (2 references)
pkts bytes target prot opt in out source destination
775 117K PRE_public_log all -- * * 0.0.0.0/0 0.0.0.0/0
775 117K PRE_public_deny all -- * * 0.0.0.0/0 0.0.0.0/0
775 117K PRE_public_allow all -- * * 0.0.0.0/0 0.0.0.0/0

Chain PRE_public_allow (1 references)
pkts bytes target prot opt in out source destination

Chain PRE_public_deny (1 references)
pkts bytes target prot opt in out source destination

Chain PRE_public_log (1 references)
pkts bytes target prot opt in out source destination

Chain PRE_trusted (2 references)
pkts bytes target prot opt in out source destination
0 0 PRE_trusted_log all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 PRE_trusted_deny all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 PRE_trusted_allow all -- * * 0.0.0.0/0 0.0.0.0/0

Chain PRE_trusted_allow (1 references)
pkts bytes target prot opt in out source destination

Chain PRE_trusted_deny (1 references)
pkts bytes target prot opt in out source destination

Chain PRE_trusted_log (1 references)
pkts bytes target prot opt in out source destination

ferrari 07-28-2020 03:04 AM

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
As your rules are lengthy though it might only show the first pageful in the terminal.

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.

THawk254 07-29-2020 01:31 AM

Quote:

Originally Posted by ferrari (Post 6150117)
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
As your rules are lengthy though it might only show the first pageful in the terminal.

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.

will I be able to save the results or will this be happening in real time?

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.

ferrari 07-29-2020 02:08 AM

Quote:

will I be able to save the results or will this be happening in real time?
You can use the approach described in the link to save two (or more) captures and then use 'diff' to show the difference between the files.

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.
I did hint at a minimal iptables config (refer post #14 link) which just shows what is needed to allow OpenVPN (single interface config), but I'm sure you could tweak that as necessary for your situation. Once you have a working iptables config, it's not hard to config firewalld based on the required iptables rules.

THawk254 07-29-2020 02:32 AM

Quote:

Originally Posted by ferrari (Post 6150508)
You can use the approach described in the link to save two (or more) captures and then use 'diff' to show the difference between the files.


I did hint at a minimal iptables config (refer post #14 link) which just shows what is needed to allow OpenVPN (single interface config), but I'm sure you could tweak that as necessary for your situation. Once you have a working iptables config, it's not hard to config firewalld based on the required iptables rules.

Read the link again and yes, I did see it. I'll have to scrounge up another CPU and ask my ISP for another public IP address to test on. I can establish the VPN link inside the LAN but hitting the public IP is a whole different ballgame. I'll be back...

THawk254 11-10-2020 11:00 PM

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

ferrari 11-10-2020 11:38 PM

The TLS error caught my attention...
Code:

TLS Error: reading acknowledgement record from packet
See if this advice helps...
http://www.f15ijp.com/2010/08/openvp...d-from-packet/

THawk254 11-10-2020 11:41 PM

Quote:

Originally Posted by ferrari (Post 6184248)
The TLS error caught my attention...
Code:

TLS Error: reading acknowledgement record from packet
See if this advice helps...
http://www.f15ijp.com/2010/08/openvp...d-from-packet/

the key is indeed present but I don't reference it in the server and client config files (i.e. it's physically there but not part of the config files). Does it matter -- i.e. if I'm not using it for simplicity of the config should I just delete it?


All times are GMT -5. The time now is 04:25 AM.