OpenVPN client blocks incoming external connections

Question

An OpenVPN connection (a Linux-like homebrew package on macOS) to my office works flawlessly, but it blocks incoming HTTP(S) traffic from my external IP address; however, when I turn off OpenVPN, I can access my computer from outside, otherwise it is blocked.

How can I configure OpenVPN to allow incoming connections over ports 80 and 443, as if there were no VPN?

• Client config:

  client
  
  dev tun
  proto udp
  remote my-server-1 1194
  
  resolv-retry infinite
  nobind
  persist-key
  persist-tun
  
  ca ca.crt
  cert client.crt
  key client.key
  remote-cert-tls server
  tls-auth ta.key 1
  cipher AES-256-CBC
  
  verb 3
  

• Server config

  port 1194
  proto udp
  dev tun
  
  ca ca.crt
  cert server.crt
  key server.key  
  dh dh2048.pem
  
  server 10.8.0.0 255.255.255.0
  ifconfig-pool-persist ipp.txt
  
  keepalive 10 120
  
  tls-auth ta.key 0 
  cipher AES-256-CBC
  
  persist-key
  persist-tun
  
  status openvpn-status.log
  verb 3
  
  explicit-exit-notify 1
  

  
  
• Output of netstat -rn without VPN:

  Internet:
  Destination        Gateway            Flags           Netif Expire
  default            192.168.0.254      UGScg             en0       
  127                127.0.0.1          UCS               lo0       
  127.0.0.1          127.0.0.1          UH                lo0       
  169.254            link#6             UCS               en0      !
  192.168.0          link#6             UCS               en0      !
  192.168.0.187/32   link#6             UCS               en0      !  # my macbook
  192.168.0.254/32   link#6             UCS               en0      !  # router
  192.168.0.254      0:1e:e5:6d:91:fb   UHLWIir           en0   1195
  192.168.0.255      ff:ff:ff:ff:ff:ff  UHLWbI            en0      !
  192.168.56         link#17            UC           vboxnet0      !
  192.168.56.255     ff:ff:ff:ff:ff:ff  UHLWbI       vboxnet0      !
  224.0.0/4          link#6             UmCS              en0      !
  224.0.0.251        1:0:5e:0:0:fb      UHmLWI            en0       
  255.255.255.255/32 link#6             UCS               en0      !
  255.255.255.255    ff:ff:ff:ff:ff:ff  UHLWbI            en0      !
  

• Output of netstat -rn with VPN: (utun3 are VPN records)

  Internet:
  Destination        Gateway            Flags           Netif Expire
  0/1                10.8.0.5           UGScg           utun3       
  default            192.168.0.254      UGScg             en0       
  10.8/24            10.8.0.5           UGSc            utun3     
  10.8.0.1/32        10.8.0.5           UGSc            utun3       
  10.8.0.5           10.8.0.6           UHr             utun3       
  127                127.0.0.1          UCS               lo0       
  127.0.0.1          127.0.0.1          UH                lo0       
  128.0/1            10.8.0.5           UGSc            utun3       
  169.254            link#6             UCS               en0      !
  192.168.0          link#6             UCS               en0      !
  192.168.0.187/32   link#6             UCS               en0      !  # my macbook
  192.168.0.254/32   link#6             UCS               en0      !  # router
  192.168.0.254      0:1e:e5:6d:91:fb   UHLWIir           en0   1162
  192.168.0.255      ff:ff:ff:ff:ff:ff  UHLWbI            en0      !
  192.168.56         link#17            UC           vboxnet0      !
  192.168.56.255     ff:ff:ff:ff:ff:ff  UHLWbI       vboxnet0      !
  <VPN IP>/32        192.168.0.254      UGSc              en0         # VPN server public IP
  224.0.0/4          link#6             UmCS              en0      !
  224.0.0.251        1:0:5e:0:0:fb      UHmLWI            en0       
  255.255.255.255/32 link#6             UCS               en0      !
  255.255.255.255    ff:ff:ff:ff:ff:ff  UHLWbI            en0      !
  

Answer 1

It's a routing issue, unfortunately I fear there may not be an easy and satisfactory answer.

Normal IP routing only cares about the destination of a packet, not it's source. In the open internet asymmetric routing is common and not necessarily a problem, but it can become a big problem when NATs, firewalls, ingress filtering etc become involved.

Without the VPN, the client sends packets to your network's NAT router, which modifies the destination address and sends them on to your computer. Your computer then generates a reply, looks up the destination address in it's routing table and sends it back out via your network's NAT router, which performs the reverse translation and puts the packet back out onto the internet where it will be delivered to the client.

When you bring up the VPN your default route is changed to point down the VPN, this means connections you initiate to the internet go down the VPN, but it also means that replies to connection requests you receive from the internet go down the VPN.

These replies will almost certainly not be delivered to the client in a usable form. Since the return packets do not pass through the NAT that performed the forward translation, the reverse translation will not be correctly performed. The response packet may be dropped by a filter, it may be forwarded to the client with no reverse translation at all, or it may be forwarded to the client with an incorrect translation. Ultimately the client either doesn't receive the packet at all or receives it with an incorrect source address and is unable to match it up with the connection attempt, either way the attempt to establish a connection fails.