NAT-T VPN - What ports are needed to access through a firewall?

This post relates to a IPSEC/ISAKMP connection enabled with the NAT-T feature and establishing its ports used through a firewall.

Basic topology per the below diagram:

Two routers R1 and R3 build a VPN to each other across a NAT translating device (R2).

R1 Configuration:
crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key password address 1.1.1.6
crypto isakmp nat keepalive 10
!
!
crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac
!
crypto map VPN_MAP 1 ipsec-isakmp
 set peer 1.1.1.6
 set transform-set 3DES-MD5
 match address VPN_ACL

!

interface FastEthernet0/0

 ip address 192.168.0.1 255.255.255.0

!

interface FastEthernet0/1

 ip address 1.1.1.1 255.255.255.252

 crypto map VPN_MAP

!

ip route 0.0.0.0 0.0.0.0 1.1.1.2

!

ip access-list extended VPN_ACL

 permit ip 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255

R2 Configuration:
interface FastEthernet0/0
 ip address 1.1.1.2 255.255.255.252
 ip nat inside
!
interface FastEthernet0/1
 ip address 1.1.1.5 255.255.255.252
 ip nat outside
!
ip nat inside source list NAT_ACL interface FastEthernet0/1 overload
!
ip access-list extended NAT_ACL
 permit ip any any

R3 Configuration:
crypto keyring spokes
  pre-shared-key address 0.0.0.0 0.0.0.0 key password
!
crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp nat keepalive 10
crypto isakmp profile L2L
   keyring spokes
   match identity address 0.0.0.0
!
crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac
!
crypto dynamic-map DYN_MAP 1
 set transform-set 3DES-MD5
 set isakmp-profile L2L
!
crypto map VPN_MAP 1 ipsec-isakmp dynamic DYN_MAP

!

interface FastEthernet0/0

 ip address 192.168.1.1 255.255.255.0

!

interface FastEthernet0/1

 ip address 1.1.1.6 255.255.255.252

 crypto map VPN_MAP

!

ip route 0.0.0.0 0.0.0.0 1.1.1.5

!

ip access-list extended VPN_ACL

 permit ip 192.168.1.0 0.0.0.255 192.168.0.0 0.0.0.255

Evidence:

VPN is active:

R1#show crypto isa sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
1.1.1.6         1.1.1.1         QM_IDLE           1002    0 ACTIVE

R3#show crypto isa sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
1.1.1.6         1.1.1.5         QM_IDLE           1002    0 ACTIVE

NAT-T Ports Used:

R2#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
udp 1.1.1.5:500        1.1.1.1:500        1.1.1.6:500        1.1.1.6:500
udp 1.1.1.5:4500       1.1.1.1:4500       1.1.1.6:4500       1.1.1.6:4500

So there you have it. UDP/500 and UDP/4500 are used for the ISAKMP and NAT-T IPSEC accordingly.

Route Filtering - Prefix Lists - LE and GE Examples

I always get the le and ge confused when I write prefix-lists to filter routes. I think I get a mental hang-up trying to get my head around the "more specific than x" is equal to "greater than x length subnet mask". I did a lab this afternoon because I had to provide a filter and decided to write down the results into this blog so I can reference in the future. Hope it does help someone else.

Topology is as per the below points:

• R1 and R2 have BGP adjacency across 1.1.1.0/30 network. 
• R1 has LAN interfaces 192.168.3.1/28 and 192.168.3.250/30. 

In the below examples we look at "matching the /30 routes only within the /24 range" as one example and "matching the smaller routes within the /24" as a second example. The last example we "match routes that are /28 to /29 in length from within the /24" by chaining both le and ge together.

Match all /30 routes within larger supernet

I wanted to write a prefix-list that would:

• Advertise /30 routes only from within the 192.168.3.0/24 supernet (i.e don't advertise 192.168.3.0/28 but advertise 192.168.3.250/30)

The below achieves that:

R1#router bgp 1

 no synchronization

 bgp log-neighbor-changes

 network 1.1.1.0 mask 255.255.255.252

 network 192.168.3.0 mask 255.255.255.240

 network 192.168.3.252 mask 255.255.255.252

 timers bgp 5 20

 neighbor 1.1.1.2 remote-as 2

 neighbor 1.1.1.2 soft-reconfiguration inbound

 neighbor 1.1.1.2 route-map BGP-OUT out

 no auto-summary

!

route-map BGP-OUT permit 10

 match ip address prefix-list TEST

!

ip prefix-list TEST seq 5 permit 192.168.3.0/24 ge 30

In the above we match /30 routes only within the /24 supernet. Below is the output proving it. You can see that we don't advertise the 192.168.3.0/28 route we have.

R1#show ip bgp neigh 1.1.1.2 advertised-routes

BGP table version is 6, local router ID is 192.168.3.253

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 192.168.3.252/30 0.0.0.0                  0         32768 i

Total number of prefixes 1

Match all smaller routes within larger supernet

I wanted to write a prefix-list that would:

• Advertise all smaller routes within a specific supernet (192.168.3.0/24)

The below achieves that:

R1#router bgp 1

 no synchronization

 bgp log-neighbor-changes

 network 1.1.1.0 mask 255.255.255.252

 network 192.168.3.0 mask 255.255.255.240

 network 192.168.3.252 mask 255.255.255.252

 timers bgp 5 20

 neighbor 1.1.1.2 remote-as 2

 neighbor 1.1.1.2 soft-reconfiguration inbound

 neighbor 1.1.1.2 route-map BGP-OUT out

 no auto-summary

!

route-map BGP-OUT permit 10

 match ip address prefix-list TEST

!

ip prefix-list TEST seq 5 permit 192.168.3.0/24 le 32

In the above I match routes that have a subnet mask between /24 and /32. Below is evidence of this being true (note that both the /28 and /30 routes are advertised):

R1#show ip bgp neigh 1.1.1.2 advertised-routes

BGP table version is 8, local router ID is 192.168.3.253

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 192.168.3.0/28   0.0.0.0                  0         32768 i

*> 192.168.3.252/30 0.0.0.0                  0         32768 i

Total number of prefixes 2

Match /28 to /29 routes from within a supernet

I wanted to write a prefix-list that would:

• Advertise only routes that are between /28 and /29 in length from within a specific supernet (192.168.3.0/24)

The below achieves that:

R1#router bgp 1

 no synchronization

 bgp log-neighbor-changes

 network 1.1.1.0 mask 255.255.255.252

 network 192.168.3.0 mask 255.255.255.240

 network 192.168.3.252 mask 255.255.255.252

 timers bgp 5 20

 neighbor 1.1.1.2 remote-as 2

 neighbor 1.1.1.2 soft-reconfiguration inbound

 neighbor 1.1.1.2 route-map BGP-OUT out

 no auto-summary

!

route-map BGP-OUT permit 10

 match ip address prefix-list TEST

!

ip prefix-list TEST seq 5 permit 192.168.3.0/24 ge 28 le 29

In the above I match routes that have a subnet mask between /28 and /29 only from within the /24 supernet. Below is evidence of this being true (note: that we only advertise the /28 route as it is the only one meeting the criteria):

R1#show ip bgp neigh 1.1.1.2 advertised-routes

BGP table version is 8, local router ID is 192.168.3.253

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 192.168.3.0/28   0.0.0.0                  0         32768 i

Total number of prefixes 1

3850 Switch Stacks - StackCabling and Switch Renumbering?

I'm not sure why but I've always found the switch renumbering command confusing to understand on 3750/3750-X/3850 switch stacks. Mostly because I wondered what happens when you renumber two switches at the same time with overlaps? i.e. You want Switch 1 to be "4", Switch 4 to be "3", etc.

First thing first, for a switch stack you don't need to cable them in specific pattern or arrangement. As long as every switch is connected in a big uninterrupted loop it will work it out and you'll be fine. For a stack of four switches here are some options:



Which is best? Really it all depends on how they are deployed in a rack or across racks and what length stack-cables you have. The default is 50cm but longer cables can be ordered (I think 3m is the max).

For the 3750X/3850 don't forget you also have StackPower cables to worry about as well.

So back to the main topic, how does the switch renumbering work... I had a stack of 4 switches I built recently. After connecting and booting them all it turned out that...

Switch 1 thinks its stack member 2
Switch 2 thinks its stack member 4
Switch 3 thinks its stack member 3
Switch 4 thinks its stack member 1

The switch renumber command swaps a single switch with the number of another switch. Logically this shouldn't work as I had multiple overlaps in the above. I gave it a go regardless. So in the above I tried to:

• Swap 1 & 2
• Swap 2 & 4
• Swap 4 & 1

It didn't work. :) I ended up with another mess altogether.

The best way I've found to do this is to do all the renumber commands you can without overlapping with the previously applied renumber commands. Then you need to reboot! Once that's done renumber out the remaining switch members and reboot... again. This chews up time since the reboot takes roughly 10mins for 3850 switches.

Lastly, you can figure out which switch is which switch member based on the lights on the front of the chassis. Highlight the "stack" LED by pressing the mode button and the switchports LEDs instead indicate the "stack" member number.

Thanks for reading. Hope it helps.

Nexus - SSH Error

Working on a Nexus 5548 last week I came across the following error when trying to SSH to another switch from here.

CORE-01# ssh admin@10.113.150.252
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is70:81:d5:1e:64:51:e5:ba:2d:9a:55:8d:fa:43:59:b8.
Please contact your system administrator.
Add correct host key in /var/home/admin/.ssh/known_hosts to get rid of this message.
Offending key in /var/home/admin/.ssh/known_hosts:8
RSA host key for 10.1.150.252 has changed and you have requested strict checking.
Host key verification failed.

Solution is pretty easy...

CORE-01# clear ssh hostsCORE-01# ssh admin@10.1.150.252
The authenticity of host '10.1.150.252 (10.113.150.252)' can't be established.
RSA key fingerprint is 70:81:d5:1e:64:51:e5:ba:2d:9a:55:8d:fa:43:59:b8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.1.150.252' (RSA) to the list of known hosts.
admin@10.1.150.252's password:
Type help or '?' for a list of available commands.
EDGE-01> en
Password: *********

This happens when the Nexus switch has a pre-existing SSH key stored for the remote device and the remote device's key changes. The command simply clears the buffer of local SSH keys stored for remote hosts. I've seen this on Linux servers before as well.

Hope it helps. Thanks for reading.