When connecting via VPN, access to the server by external ip disappears?

Question

VPN

Hello!
Another stupid question related to iptables. There is a server on ubuntu server 16. On it, softether vpn server works as a VPN. On the server, br0 is raised - which is a "local network bridge", it only includes tap_soft (the interface that raises softether), but I plan to add another vpn (wireguard did not want to be added to the bridge). Masgarding is configured, the Internet works. There is also a dhcp server that distributes the 192.168.4.0\255.255.255.0 subnet to the bridge.
There is one BUT - when a client connects to vpn, then the external ip address of the server becomes unavailable for him, respectively, access to server resources by domain name does not work.
Here are the rules that iptables-persistent loads. Yes, and the server itself is on a virtual machine and access to ens3 from the outside is open only from 5 ports, so I practically do not block anything here. wg0 - this was the wireguard interface, now I have disabled it.

# Completed on Wed Nov  8 01:03:03 2017
# Generated by iptables-save v1.6.0 on Wed Nov  8 01:03:03 2017
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i tap_soft -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A INPUT -i wg0 -j ACCEPT

-A FORWARD -i br0 -o ens3 -j ACCEPT
-A FORWARD -i ens3 -o br0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ens3 -o br0 -j REJECT --reject-with icmp-host-prohibited

-A FORWARD -i wg0 -o ens3 -j ACCEPT
-A FORWARD -i ens3 -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ens3 -o wg0 -j REJECT --reject-with icmp-host-prohibited

-A FORWARD -i tap_soft -o ens3 -j ACCEPT
-A FORWARD -i ens3 -o tap_soft -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ens3 -o tap_soft -j REJECT --reject-with icmp-host-prohibited

-I FORWARD -s 192.168.4.1 -p udp --sport 1:65000 -j ACCEPT
-I FORWARD -s 192.168.4.1 -p tcp --sport 1:65000 -j ACCEPT

-A FORWARD -i br0 -j ACCEPT
-A FORWARD -i wg0 -j ACCEPT
-A FORWARD -i tap_soft -j ACCEPT

-A OUTPUT -o br0 -j ACCEPT
-A OUTPUT -o wg0 -j ACCEPT
-A OUTPUT -o tap_soft -j ACCEPT

COMMIT
# nat Table rules
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
#-A PREROUTING -d <внешний ip> -p udp --dport 1:65500 -j DNAT --to-destination 192.168.4.1
#-A POSTROUTING -s 192.168.4.1 -j SNAT --to-source <внешний ip>
#-I PREROUTING -d <внешний ip> -p tcp --dport 1:65500 -j DNAT --to-destination 192.168.4.1
#-I POSTROUTING -s 192.168.4.1 -j SNAT --to-source <внешний ip>

-A POSTROUTING -o ens3 -j MASQUERADE
COMMIT
# Completed on Wed Nov  8 01:03:03 2017

Here is the output of ifconfig:

br0       Link encap:Ethernet  HWaddr 00:ac:5d:bc:9c:d4
          inet addr:192.168.4.1  Bcast:192.168.4.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14216 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14930 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2754841 (2.7 MB)  TX bytes:15078862 (15.0 MB)

ens3      Link encap:Ethernet  HWaddr 52:54:00:29:0c:a0
          inet addr:<внешний ip>  Bcast:xx.xxx.xxx.xxx  Mask:255.255.254.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7802578 errors:0 dropped:45 overruns:0 frame:0
          TX packets:72759 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:561349369 (561.3 MB)  TX bytes:28622214 (28.6 MB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:2262045 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2262045 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:562016816 (562.0 MB)  TX bytes:562016816 (562.0 MB)

tap_soft  Link encap:Ethernet  HWaddr 00:ac:5d:bc:9c:d4
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14216 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17913 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2953865 (2.9 MB)  TX bytes:15239944 (15.2 MB)

virbr0    Link encap:Ethernet  HWaddr 52:54:00:8c:18:62
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Thank you.

Answer 1

It is very unlikely that there is no access to the server address, otherwise the vpn tunnel fell off by timeout immediately after connecting, then connected again and fell off again. Look at the routing table on the client and see for yourself.
I would advise giving VPN clients a domain record looking at the IP address of the VPN interface (192.168.4.1), if there is a DNS server on the server.
If not, then google for the key "Iptables Nat Loopback"