OpenVPN use an internal address 192.168.100.2 to route the traffic.
It conflict with the VLAN440 address of pushkin and avoid to access it through this address.
The quick solution is to move pushkin to 192.168.100.4
(louvre must be moved to 192.168.100.5 before)
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Migrated | gitlab-migration | T3444 26/07/2021: Unstuck infrastructure outage then post-mortem | ||
| Migrated | gitlab-migration | T3460 Restore access to the gui of the passive firewall |
root@louvre:~# diff -u3 /tmp/interfaces /etc/network/interfaces --- /tmp/interfaces 2021-08-05 12:44:20.213896058 +0000 +++ /etc/network/interfaces 2021-08-05 12:37:29.480805493 +0000 @@ -5,7 +5,7 @@ auto ens18 iface ens18 inet static - address 192.168.100.4 + address 192.168.100.5 netmask 255.255.255.0 gateway 192.168.100.1
the pushkin's ip was changed and the new ip was declared on puppet.
It seems the firewall is still not reachable with the new ip.
I'm trying to diagnose the problem
well I have misinterpreted the routing issue.
It seems it's only because the openvpn service is also started on pushkin (it's normal to be ready in case of a primary/secondary switch).
The route for the openvpn traffic is also declared on the secondary so a packet from the VPN is falling in a black hole:
packet from openvpn client to 192.168.100.4 -> openvpn (glyptotek) -> pushkin through vnet1 -> openvpn (pushkin) (wrong route, the packet is lost)
I will rollback the ip changes because it's not solving anything and document a way to access to the secondary through the vpn