SSL VPN ip overlap with Secuextender Mac OS

Fred_77

Hi guys, does anyone know if there is a bug / problem with the Mac Os version of Secuextender SSL when the remote client is in the same subnet as the headquarters? Even if "Force all traffic ..." is selected,  VPN is established, but no ping, no routing, no internet connection ....

Same situation with Win Client no problem.

Thanks in advance

mMontana

@Fred_77 would you please share some (private) subnets?
Also with the "lan" for the Windows and MacOS client...

Consider to publish also (if possible) the output for obtaining routing tables. I feel that the "kind" of network connection may be a part of the issue solving...

Fred_77

Hi @mMontana, thanks for reply.
my scenario is quite easy:


ATP200 with latest fw release,
LAN1 192.168.1.XXX (sob! i know it's very common but i can't modify)
Assigned VPN IP 192.168.13.10>100

Remote client subnet 192.168.1.XXX 

If the remote is a windows client everything is ok.

If the remote is a MAC OS (my tests with Mac Os 12) i can ping client from ATP on sub192.168.13.XXX and ATP from client 192.168.200.1 but nothing else.

Switching MAC OS network to LTE hotspot (192.168.43.XXX) everything is ok

PeterUK

Fred_77 said:

ATP200 with latest fw release,
LAN1 192.168.1.XXX (sob! i know it's very common but i can't modify)

Why not? have the client change their routers LAN? 

Fred_77

It sounds incredible...
I inherited this infrastructure and there are plc's "so special" that to change IP a dude has to come to Italy from Belgium. And  cost a lot.

No comment...
Obviusly the customer will have them modified when they will do maintenance on the machinery.
he's a bit stingy   
 
 

mMontana

IMVHO part of the issue is due to the way that Windows manage routes.
Cable LAN drivers have higher priority on routing table compared to wireless drivers.
Then... SSL VPN is a modified OpenVPN driver by Zyxel, but as windows perspective is a LAN card.
Which is not for MacOSX.  Currently I do not have access on a Mac OS device to run some tests... and point you to a way to esplain to MacOS X that SSL VPN adapter should have priority on routing tables.

As for...
LAN1 192.168.1.XXX (sob! i know it's very common but i can't modify)
It's simply a IT management suicide. 

If your SSL VPN users do not ever come into LAN1, you can use Destination NAT to "create" a different LAN1 subnet for who comes from SSL VPN. I'm quite certain that with L2TP is available, did never check for SSL VPN.

Fred_77

@mMontana

mMontana said:

If your SSL VPN users do not ever come into LAN1, you can use Destination NAT to "create" a different LAN1 subnet for who comes from SSL VPN. I'm quite certain that with L2TP is available, did never check for SSL VPN.

Yes, it's available on L2TP, i can check for SSL VPN

maybe...

thanks guys
enjoy the week end

Zyxel_Jeff

Normally, to avoid the VPN traffic routing issue of overlap subnet. 

We would recommend users to separate the subnet.

mMontana

@Zyxel_Jeff any network sysadmin knows this quite obvious rule of thumb...

Fred_77

Hi @Zyxel_Jeff
the focus is another: try to understan why (in the same condition) a Win client works well and a Mac OS does not

PeterUK

Different network TCP/IP stack in Win vs Mac