AWS Client VPN macOS 3.7.0 split-tunnel not working

0

Hi,

I have an AWS Client VPN endpoint with Split-Tunnel Enabled configured.

After upgrading to the macOS AWS VPN Client 3.7.0, it appears like the split tunnel functionality is not working anymore.

I can see the default route 0.0.0.0/0 being configured route via the tunnels IP. It is however not part of my Client VPN endpoints route table.

For full transparency, there are the routes that are part of my Client VPN endpoints route table: 10.0.0.0/16, 10.2.0.0/16, 192.9.200.0/24, 192.168.190.0/24, 10.1.0.0/16.

From /tmp/AcvcHelperOutLog.txt:

15:12:04 *UpScript:  **********************************************
15:12:04 *UpScript:  Start of output from client.up
15:12:06 *UpScript:  Retrieved from OpenVPN: name server(s) [ 10.0.0.2 ], search domain(s) [ ] and SMB server(s) [ ] and using default domain name [ openvpn ]
15:12:07 *UpScript:  Not aggregating ServerAddresses because running on macOS 10.6 or higher
15:12:07 *UpScript:  Setting search domains to 'openvpn' because the search domains were not set manually (or are allowed to be changed) and 'Prepend domain name to search domains' was not selected
15:12:08 *UpScript:  Saved the DNS and SMB configurations so they can be restored
15:12:09 *UpScript:  Changed DNS ServerAddresses setting from '192.168.178.1 fd00::3e37:12ff:fedb:4e1d 2a02:8109:b317:ed00:3e37:12ff:fedb:4e1d' to '10.0.0.2'
15:12:09 *UpScript:  Changed DNS SearchDomains setting from 'fritz.box' to 'openvpn'
15:12:09 *UpScript:  Changed DNS DomainName setting from '' to 'openvpn'
15:12:09 *UpScript:  Did not change SMB NetBIOSName setting of ''
15:12:09 *UpScript:  Did not change SMB Workgroup setting of ''
15:12:09 *UpScript:  Did not change SMB WINSAddresses setting of ''
15:12:09 *UpScript:  DNS servers '10.0.0.2' will be used for DNS queries when the VPN is active
15:12:09 *UpScript:  NOTE: The DNS servers do not include any free public DNS servers known to Tunnelblick. This may cause DNS queries to fail or be intercepted or falsified even if they are directed through the VPN. Specify only known public DNS servers or DNS servers located on the VPN network to avoid such problems.
15:12:09 *UpScript:  Writing DNS server information to disk for application to verify
15:12:09 *UpScript:  End of output from client.up
15:12:09 *UpScript:  **********************************************
Sun Aug 20 15:12:09 2023 /sbin/route add -net 52.57.13.26 192.168.178.1 255.255.255.255
add net 52.57.13.26: gateway 192.168.178.1
Sun Aug 20 15:12:09 2023 /sbin/route add -cloning -net 192.168.178.1 -netmask 255.255.255.255 -interface en6
add net 192.168.178.1: gateway en6
Sun Aug 20 15:12:09 2023 /sbin/route delete -net 0.0.0.0 192.168.178.1 0.0.0.0
delete net 0.0.0.0: gateway 192.168.178.1
Sun Aug 20 15:12:09 2023 /sbin/route add -net 0.0.0.0 10.0.120.1 0.0.0.0
add net 0.0.0.0: gateway 10.0.120.1
Sun Aug 20 15:12:09 2023 MANAGEMENT: >STATE:1692537129,ADD_ROUTES,,,,,,
Sun Aug 20 15:12:09 2023 /sbin/route add -net 10.2.0.0 10.0.120.1 255.255.0.0
add net 10.2.0.0: gateway 10.0.120.1
Sun Aug 20 15:12:09 2023 /sbin/route add -net 192.168.190.0 10.0.120.1 255.255.255.0
add net 192.168.190.0: gateway 10.0.120.1
Sun Aug 20 15:12:09 2023 /sbin/route add -net 10.1.0.0 10.0.120.1 255.255.0.0
add net 10.1.0.0: gateway 10.0.120.1
Sun Aug 20 15:12:09 2023 /sbin/route add -net 10.0.0.0 10.0.120.1 255.255.0.0
add net 10.0.0.0: gateway 10.0.120.1
Sun Aug 20 15:12:09 2023 /sbin/route add -net 192.9.200.0 10.0.120.1 255.255.255.0
add net 192.9.200.0: gateway 10.0.120.1
Sun Aug 20 15:12:09 2023 /sbin/route add -net 192.168.178.128 10.0.120.1 255.255.255.128
add net 192.168.178.128: gateway 10.0.120.1
Sun Aug 20 15:12:09 2023 /sbin/route add -net 192.168.178.0 10.0.120.1 255.255.255.128
add net 192.168.178.0: gateway 10.0.120.1

After downgrading to 3.2.0 of AWS VPN Client, this is the same section of the log. Not that there is no route change to 0.0.0.0 as expected from a Split-Tunnel VPN configuration.

Sun Aug 20 15:26:01 2023 /Applications/AWS VPN Client/AWS VPN Client.app/Contents/Resources/openvpn/client.up utun4 1500 1552 10.0.120.34 255.255.255.224 init
15:26:01 *UpScript:  **********************************************
15:26:01 *UpScript:  Start of output from client.up
15:26:03 *UpScript:  Retrieved from OpenVPN: name server(s) [ 10.0.0.2 ], search domain(s) [ ] and SMB server(s) [ ] and using default domain name [ openvpn ]
15:26:03 *UpScript:  Not aggregating ServerAddresses because running on macOS 10.6 or higher
15:26:03 *UpScript:  Setting search domains to 'openvpn' because the search domains were not set manually (or are allowed to be changed) and 'Prepend domain name to search domains' was not selected
15:26:05 *UpScript:  Saved the DNS and SMB configurations so they can be restored
15:26:05 *UpScript:  Changed DNS ServerAddresses setting from '192.168.178.1 fd00::3e37:12ff:fedb:4e1d 2a02:8109:b317:ed00:3e37:12ff:fedb:4e1d' to '10.0.0.2'
15:26:05 *UpScript:  Changed DNS SearchDomains setting from 'fritz.box' to 'openvpn'
15:26:05 *UpScript:  Changed DNS DomainName setting from '' to 'openvpn'
15:26:05 *UpScript:  Did not change SMB NetBIOSName setting of ''
15:26:05 *UpScript:  Did not change SMB Workgroup setting of ''
15:26:05 *UpScript:  Did not change SMB WINSAddresses setting of ''
15:26:05 *UpScript:  DNS servers '10.0.0.2' will be used for DNS queries when the VPN is active
15:26:05 *UpScript:  NOTE: The DNS servers do not include any free public DNS servers known to Tunnelblick. This may cause DNS queries to fail or be intercepted or falsified even if they are directed through the VPN. Specify only known public DNS servers or DNS servers located on the VPN network to avoid such problems.
15:26:05 *UpScript:  Writing DNS server information to disk for application to verify
15:26:05 *UpScript:  End of output from client.up
15:26:05 *UpScript:  **********************************************
Sun Aug 20 15:26:05 2023 MANAGEMENT: >STATE:1692537965,ADD_ROUTES,,,,,,
Sun Aug 20 15:26:05 2023 /sbin/route add -net 10.2.0.0 10.0.120.33 255.255.0.0
add net 10.2.0.0: gateway 10.0.120.33
Sun Aug 20 15:26:05 2023 /sbin/route add -net 192.168.190.0 10.0.120.33 255.255.255.0
add net 192.168.190.0: gateway 10.0.120.33
Sun Aug 20 15:26:05 2023 /sbin/route add -net 10.1.0.0 10.0.120.33 255.255.0.0
add net 10.1.0.0: gateway 10.0.120.33
Sun Aug 20 15:26:05 2023 /sbin/route add -net 10.0.0.0 10.0.120.33 255.255.0.0
add net 10.0.0.0: gateway 10.0.120.33
Sun Aug 20 15:26:05 2023 /sbin/route add -net 192.9.200.0 10.0.120.33 255.255.255.0
add net 192.9.200.0: gateway 10.0.120.33

Let me know if you need more information and if there is a workaround of configuration change I can make to fix this.

asked a year ago326 views
2 Answers
0
Accepted Answer

The 3.9.0 has fixed this behaviour.

answered 10 months ago
  • I still have the same problems in 3.9.0 - is it possibly not resolved?

    I get this in my routing table after connecting to the VPN with Split Tunnel enabled. It's also a new thing for me - I had no problems with this before.

    Routing tables

    Internet: Destination Gateway Flags Netif Expire default 172.23.1.33 UGScg utun8

0

This is still the case on the 3.8.0 release. Does anyone have any idea or need more input to debug? Happy to provide it if anything else is needed.

answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions