My guess is that the server receives the packet from the client with src .11.101 dst .10.102 and tries to respond over the interface that has .11.102 assigned. The client expects a response from src .10.102 and drops the packet. But I would turn on a packet sniffer in the gateway to see if the returning traffic even passes the Firewall in scenario 1.
Went from rif to connect for Lemmy and i’m happy with it
Reset the AP to make sure it uses dhcp for its own ip and update firmware from unifi network after adopting the AP again.
Test it by swapping places of the access points to find out if the issue is related to the access points or something else.
Cersei Lannister - Lena Heady must get just as much of random hate from people as Jack Gleeson does.
Vincent D’Onofrio probably gets a lot of weird interactions from people that saw him in daredevil or Full metal jacket too.
Två main reasons:
OpenVPN connect on both. I load the .ovpn-file that is exported from the server and that’s it.
Personally I would have gone for OpenVPN access server on Debian. Fairly simple and well documented for those starting out.
I have used and worked with OpenVPN connect on android, PC and Mac.
It also comes with a dyndns-client built in. Very useful for updating the address of the OpenVPN server.
It has to do with link priority on the server. You’d imagine that a server that receives a packet that has a return address on the same subnet as it self logically would use that interface instead.
A similar thing happens in switches. For example if you have two vlans on a switch and both vlans have an ip assigned, connect a computer to one of the vlans. You will only be able to reach the switch on the non-routed connection. Even if you also are allowed to reach the second vlan through a router/Firewall.