Cisco AnyConnect Client squashing other VPN client routes when there is split tunnel overlap

Consider a VPN client such as Palo Alto GlobalProtect doing split tunneling with an include access route of 10.4.0.0/16, 10.5.0.0/16, and 10.6.0.0/16.  The client route table in Windows looks like this, as expected:

C:\Users\harold>route print

IPv4 Route Table
=======================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
10.4.0.0 255.255.0.0 On-link 10.4.1.205 1
10.5.0.0 255.255.0.0 On-link 10.4.1.205 1
10.6.0.0 255.255.0.0 On-link 10.4.1.205 1

The user then connects to a AnyConnect VPN with a split tunnel include of 10.0.0.0/8.  Something rather funny happens!

C:\Users\harold>route print

IPv4 Route Table
=======================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
10.4.0.0 255.255.0.0 On-link 10.4.1.205 1
10.4.0.0 255.255.0.0 10.8.2.1 10.8.2.27 2
10.5.0.0 255.255.0.0 On-link 10.4.1.205 1
10.5.0.0 255.255.0.0 10.8.2.1 10.8.2.27 2
10.6.0.0 255.255.0.0 On-link 10.4.1.205 1
10.6.0.0 255.255.0.0 10.8.2.1 10.8.2.27 2

AnyConnect has created duplicate routes…for routes that don’t even belong to it.  But since the metric is a higher value (2 vs. 1) these routes are ignored by Windows.  So, no harm no foul I guess?

Different story on Mac though…hmmm

 

 

 

sadf

 

Advertisement

Disabling IPv6 and DNSSEC in Bind9 / Ubuntu 16.04

We recently migrated an internal bastion host from Ubuntu 14 to 16.04.  I was able to pull secondary zones, but getting recursion working was a real problem.  The previous one would forward certain zones to other internal servers, and even thought the configuration was the same I was having zero luck:

root@linux:/etc/bind# host test.mydomain.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

Host test.mydomain.com not found: 2(SERVFAIL)

I did a tcpdump and discovered the queries were being sent to the intended forwarder just fine and valid IPs being returned:

19:11:24.180854 IP dns.cache-only.ip.46214 > dns.forwarder.ip.domain: 18136+% [1au] A? test.mydomain.com. (77)
19:11:24.181880 IP dns.forwarder.ip.domain > dns.cache-only.ip.46214: 18136 3/0/1 A 10.10.1.2, A 10.10.1.3 (125)

Grasping at straws, I theorized the two culprits could be IPv6 and DNSSec, some Googling indicated it’s a bit confusing on how to actually disable these, but I did find the answer.

Disabling IPv6 and DNSSEC

There were two steps to do this:

In /etc/default/bind9, add -4 to the OPTIONS variable

OPTIONS="-u bind -4"

In /etc/bind/named.conf.options do this

// Disable DNSSEC 
//dnssec-validation auto
dnssec-enable no;

// Disable IPv6
//listen-on-v6 { any; };
filter-aaaa-on-v4 yes;

After restarting BIND with sudo /etc/init.d/bind9 restart now we’re good:

root@linux:/etc/bind# host test.mydomain 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

test.mydomain.com has address 10.10.1.2
test.mydomain.com has address 10.10.1.3

Authenticating ZenDesk via AWS SSO

Setting up ZenDesk for AWS SSO was a bit weird due to their requirements, but not that difficult in hindsight.

  1. Copy the SSO Sign-in and Sing-out URLs to ZenDesk.
  2. For the certificate fingerprint, download the AWS SSO certificate, open it, click Details tab, and look for Thumbprint at the bottom.
  3. The Application ACS URL will be https://MYSUBDOMAIN.zendesk.com/access/saml
  4. The Application SAML audience URL will be https://MYSUBDOMAIN.zendesk.com
  5. The final step is add two custom attributes in the AWS configuration
  • name = ${user:givenName}
  • email = ${user:email}

AWSSSO_ZenDesk_AttributeMappings