1

I have a CentOS 7 system, with a VPN host and one physical network interface.

I have my physical network interface assigned to public zone, while my VPN requests are going through trusted. Also, I have some servers, in docker containers routed to the latter zone.

I'd like, if my VPN and Docker containers to have internet connection, while retaining the subnet of 10.8.0.0/24 that I created on zone trusted.

The solution I'm thinking of involves forwarding request from 10.8.0.0/24 to out of the subnet to the physical interface, preferably with masquareding. If you have a better solution, I'm open to it.

So far, my firewalld config looks like this.

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp2s0
  sources:
  services: ssh dhcpv6-client
  ports: 8080/tcp 23/tcp 1194/udp 80/tcp 443/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:


trusted (active)
  target: ACCEPT
  icmp-block-inversion: no
  interfaces: docker0
  sources: 10.8.0.0/24 2001:0db8:ee00:abcd::/64
  services: openvpn
  ports:
  protocols:
  masquerade: yes
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
  • I'm kind of confused by the question, because I only have one NIC (physical one at least), which is connected to the internet, via a router. the IP is 192.168.0.241. The VPN has a subnet of 10.8.0.0/24, and the computer in question has the address of 10.8.0.1. I was paying attention, not to have them overlap – László Stahorszki Jan 23 at 22:23
  • 1
    Okay so try this..... route add 10.8.0.0 mask 255.255.255.0 10.8.0.1 followed by route add 10.8.0.1 mask 255.255.255.255 192.168.0.241 but beforehand you might save the output of the route print somewhere to reference first. To delete those routes you can run route delete 10.8.0.0 and route delete 10.8.0.1.... Think hard about this, have backup of your route table too and be sure you can revert it back out of have a backout method just in case. – Pimp Juice IT Jan 23 at 22:26
  • 1
    If you add those two routes and there are problems, you can reboot too since they are not persistent so route add 10.8.0.0 mask 255.255.255.0 10.8.0.1 first and then route add 10.8.0.1 mask 255.255.255.255 192.168.0.241 next. If there are issues, reboot and do not run the route delete commands. Still have the route print output of the IPv4 first though. – Pimp Juice IT Jan 23 at 22:27
  • 1
    There has to be an IP on one subnet that can talk to an IP on another subnet that can then route via Layer 3 routing I think. I've configured static routes like that before on the client machines, and I've configured static routes in routers and firewalls too. There are other ways to do it with other protocols but for things like this, that's how I've handled some in the past. Maybe it will help or maybe not, let me know your thoughts. – Pimp Juice IT Jan 23 at 22:31
  • 2
    Let us continue this discussion in chat. – Pimp Juice IT Jan 23 at 22:46
0

Sorry for my absence, I had other things to do in the meantime, but I did manage to solve the problem.

However, the solution is kind of disappointing. The only thing I needed to do was to enable masquerading on the public zone

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.