Cannot reach network behind server

kb9mfd

I cannot reach anything on the local subnet of the server, the 172.28.101.0/24 subnet. the remote can ping and ssh to the server at 172.28.101.20, but if I try to reach any other address it's not working. I wiresharked tun0 and see the packets, but when I wireshark the local interface of the server I see the packets, but the something is replacing the "from" address with the wan address for some reason. I cannot figure out why. So the tun0 tcpdump is "10.8.0.101 --> 172.28.101.45" and the local interface for the same packet is "12.12.12.12 --> 172.28.101.45" where 12.12.12.12 is my WAN IP for the vpn. It's masquerading, but I have masquerade turn off entirely in FirewallD. Here is the server config -

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
#push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
route 172.28.101.0 255.255.255.0
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 10 120
cipher AES-256-CBC
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem
explicit-exit-notify

And the ccd is - (replace 101 with then next clients of 102, 103, etc...)

ifconfig-push 10.8.0.101 255.255.255.255
push "route 10.8.0.0 255.255.255.0 10.8.0.101"
push "route 172.28.101.0 255.255.255.0 10.8.0.101"

Any suggestions on this issue? Thanks!

TinCanTech

It looks like you have a lot to learn about routing, please use the internet to educate yourself.

However, this does look wrong:

kb9mfd wrote And the ccd is - (replace 101 with then next clients of 102, 103, etc...)

ifconfig-push 10.8.0.101 255.255.255.255
push "route 10.8.0.0 255.255.255.0 10.8.0.101" <-- Very wrong.
push "route 172.28.101.0 255.255.255.0 10.8.0.101"

10.8.0.0/24 is your VPN subnet and you do not need to mess around with that because it is all automatically configured by --server.

kb9mfd

TinCanTech wrote It looks like you have a lot to learn about routing, please use the internet to educate yourself.

However, this does look wrong:
kb9mfd wrote And the ccd is - (replace 101 with then next clients of 102, 103, etc...)
ifconfig-push 10.8.0.101 255.255.255.255
push "route 10.8.0.0 255.255.255.0 10.8.0.101" <-- Very wrong.
push "route 172.28.101.0 255.255.255.0 10.8.0.101"
10.8.0.0/24 is your VPN subnet and you do not need to mess around with that because it is all automatically configured by --server.

I did, henceforth why that was in there and I forgot to put it back. it was pulled from another post in a different forum on a different issue. Although it does not look right, it actually works and the route table was correct. Anyway, I put the ifconfig back to /32 and removed the extra route command. Still have the same issue. When traffic is passing from the tun0 interface to the enp3s0 interface on the server the packets are being masqueraded, at least that is the best way to explain it. Here is the tcpdump - (I replaced my wan with 12.12.12.12) on the remote I pinged 172.28.101.45 which is a computer on the same subnet as the server, and yes I do have the routes setup in my main router.

[root@masterunit ccd]# tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
09:52:07.464134 IP 10.8.0.102 > 172.28.101.45: ICMP echo request, id 29024, seq 1, length 64
09:52:08.485065 IP 10.8.0.102 > 172.28.101.45: ICMP echo request, id 29024, seq 2, length 64

[root@masterunit ccd]# tcpdump -i enp3s0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:52:20.346598 IP 12.12.12.12 > 172.28.101.45: ICMP echo request, id 29025, seq 1, length 64
09:52:21.347597 IP 12.12.12.12 > 172.28.101.45: ICMP echo request, id 29025, seq 2, length 64

server route table -

[root@masterunit ccd]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         12.12.12.13  0.0.0.0         UG    100    0        0 enp4s0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
12.12.12.10  0.0.0.0         255.255.255.248 U     100    0        0 enp4s0
172.28.101.0    0.0.0.0         255.255.255.0   U     101    0        0 enp3s0

client rote table -

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    600    0        0 wlp0s20u3
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
172.28.101.0    10.8.0.1        255.255.255.0   UG    0      0        0 tun0
172.29.100.0    0.0.0.0         255.255.255.0   U     600    0        0 wlp0s20u3
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

TinCanTech

You realise that openvpn does not do masquerading your firewall does ..

kb9mfd

TinCanTech wrote You realise that openvpn does not do masquerading your firewall does ..

I do, and I have posted this same question on a different forum in regards to the firewall. I am not not finding much out there on how to properly setup FirewallD with OpenVPN. As far as I can tell, FirewallD is suppose to be rather straight forward, not that complicated. I am use to using shorewall and would of used it instead but its not available for CentOS 8. A second related issue is if I setup my clients to use the tunnel as the default gateway, I loose my internet if I do not have masquerade on the external zone (makes sense), but I removed masquerade as you see below, but sill something is changing the packets as you saw above. If its not the firewall, not OpenVPN, then what? I accidentally put a bad route rule in "route 172.28.101.0 255.255.255.0 gw 10.8.0.2", what happened was when I did a ping and was tcpdump -i tun0 I saw the ping come in then just get reflected back to the tun0 modified with the originating address as the WAN again. Whatever is taking the packet from tun0 and then forwarding it according to the route table is also changing the originating address.

[root@masterunit ppadmin]# firewall-cmd --list-all-zones                        
block
  target: %%REJECT%%
  icmp-block-inversion: no
  interfaces:
  sources:
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:


dmz
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:


drop
  target: DROP
  icmp-block-inversion: no
  interfaces:
  sources:
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:


external (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp4s0
  sources:
  services: openvpn ssh
  ports: 1194/udp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:


home
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: cockpit dhcpv6-client mdns samba-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:


internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp3s0 tun0 wls1
  sources:
  services: bacula mdns samba-client ssh vnc-server
  ports: 10000/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:


public
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: openvpn ssh
  ports: 1194/udp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:


trusted
  target: ACCEPT
  icmp-block-inversion: no
  interfaces:
  sources:
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:


work
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

kb9mfd

Ok, I found it. I did not know I could use iptables commands with FirewallD. I found this when I did a iptables-save-

-A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source xx.xx.xx.xx

So I deleted the POSTROUTING rule. I have no idea how that got there.

[root@masterunit ppadmin]# iptables -t nat -v -L POSTROUTING -n --line-number
Chain POSTROUTING (policy ACCEPT 21 packets, 1529 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        5   302 SNAT       all  --  *      *       10.8.0.0/24         !10.8.0.0/24          to:xx.xx.xx.xx
[root@masterunit ppadmin]# iptables -t nat -D POSTROUTING 1
[root@masterunit ppadmin]# iptables -t nat -v -L POSTROUTING -n --line-number
Chain POSTROUTING (policy ACCEPT 30 packets, 2189 bytes)
num   pkts bytes target     prot opt in     out     source               destination
[root@masterunit ppadmin]#

I did a reboot, and it came back. I took a look in /etc and found a file called direct.xml in the /etc/firewalld directory that was putting that rule in place, I have no idea where that came from but I removed it. I can now ping, but something is still blocking traffic but at least ping works.