WOL Directed Broadcast Configuration on Cisco Layer 3 Switches

Use directed broadcast to configure the Wake On LAN (WOL) application on Cisco L3 switches. In our case we had the WOL servers connected to VLAN 1 (10.1.20.64 and .65). They are used to wake client computers on all other private VLANs. Here's the working example for our test case with clients on VLAN2:

access-list 180 permit udp host 10.1.20.64 any 

access-list 180 permit udp host 10.1.20.65 any

interface Vlan1 

ip address 10.1.0.10 255.255.0.0 

ip helper-address 10.2.255.255 

! 

interface Vlan2 

ip address 10.2.0.10 255.255.0.0 

ip directed-broadcast 180 

Note that the helper address sends the WOL broadcast to all destination subnets that are specified there (in our case to the 10.2.0.0/16 subnet) but you control what lands up on the destination VLAN with the directed broadcast command and an acl. It works if you use a supernet in the helper address command to cover all your destination networks.

Cisco ASA 5500 7.2x to 8.4x upgrade

I just completed this upgrade on two firewalls and want to share some issues I encountered. Our firewalls were using the following basic features:

• IPSEC VPN client
• Site to Site IPSEC VPN tunnel
• PAT
• Static NATs
• NAT exempt 

Firstly the image boots up and the new asdm works. You should have no concern about the ASA not booting up. In fact I had to do one that was located in a Data Center in Chicago and we were in California!

1. The known documented issue with the nat exempt command must be taken care of. The keyword unidirectional is added to the nat exempt (nat 0) rule which must be changed to bidirectional for each nat exempt command you have.
2. Since the new access rules now references the real IPs of translated addresses I found that none of these got changed on my outside access list! I had to change each ACL entry manually from the public address to its private IP address. 
3. There is a site to site IPSEC VPN tunnel built that references a translated IP of a local host in the encryption domain. The conversion process added a nat exempt rule for the encryption domain! This, of course, prevented the local host from being translated when it was trying to connect to the remote host across the tunnel. No match was found and so the tunnel never gets established! I removed that nat exempt rule to fix.

That's it! All the best in your upgrades.

Here is the Cisco reference to the 8.4x release notes.

IOS NAT and VPN

Building NAT (PAT or Static) on a Cisco router is fairly well documented and works well. However, I got tripped up again with an implementation today where the PAT would work but then the VPN tunnel would go down!

Case Study

My client has a site to site VPN tunnel to Cust2 with 6 remote networks. All local networks (192.168.0.0/21) communicate to the remote nets with their private IPs. In addition, the local networks get PAT'd to 39.100.3.68 when routed over to the Internet. There is one static NAT that only gets translated to  39.100.3.67 when communicating with 206.96.88.115 out on the Internet. In all other cases it will remain as it's real IP of 192.168.0.76.

Here is the configuration that I built. The VPN tunnel and static NAT rule using a route map to achieve our goal worked. However, as soon as I applied the PAT pool and overload translation, the tunnel went down.

crypto isakmp policy 10

 encr 3des

 authentication pre-share

 group 2

!

crypto isakmp policy 20

 encr aes

 authentication pre-share

 group 2

crypto isakmp key *** address 209.100.166.20

!

!

crypto ipsec transform-set 3DES-SHA esp-3des esp-sha-hmac

!

crypto map vpnmap 10 ipsec-isakmp

 set peer 209.100.166.20

 set transform-set 3DES-SHA

 match address cust2-vpn

interface GigabitEthernet0/0

 description to Inside

 ip address 192.168.0.8 255.255.255.0

 ip nat inside

!

interface GigabitEthernet0/1

 description Internet

 ip address 39.105.128.242 255.255.255.252

 ip nat outside

 crypto map vpnmap

!

ip nat pool natpool 39.100.3.68 39.100.3.68 netmask 255.255.255.0

ip nat inside source list ins_nat_source pool natpool overload

ip nat inside source static 192.168.0.76 39.100.3.67 route-map nat-exempt extendable

!

ip access-list extended cust2-vpn

 permit ip 192.168.0.0 0.0.7.255 192.168.16.0 0.0.0.255

 permit ip 192.168.0.0 0.0.7.255 70.185.0.0 0.0.255.255

 permit ip 192.168.0.0 0.0.7.255 200.106.176.0 0.0.7.255

 permit ip 192.168.0.0 0.0.7.255 200.106.184.0 0.0.1.255

 permit ip 192.168.0.0 0.0.7.255 206.184.246.0 0.0.0.255

 permit ip 192.168.0.0 0.0.7.255 208.134.161.0 0.0.0.255

ip access-list extended ins_nat_source

 deny   ip any 192.168.16.0 0.0.0.255

 deny   ip any 70.185.0.0 0.0.255.255

 deny   ip any 200.106.176.0 0.0.7.255

 deny   ip any 200.106.184.0 0.0.1.255

 deny   ip any 206.184.246.0 0.0.0.255

 deny   ip any 208.134.161.0 0.0.0.255

 permit ip any any

access-list 110 permit ip host 192.168.0.76 host 206.96.88.115

access-list 110 deny   ip host 192.168.0.76 any

!

!

!

route-map nat-exempt permit 1

 match ip address 110

!

The fix is to also include the Internet facing interface into the NAT exempt access rules (ins_nat_source). Even though that interface is on the 'outside', it will get subjected to translation because of the 'permit any any' rule. Here's the fixed access rule:

ip access-list extended ins_nat_source

 deny   ip any 192.168.16.0 0.0.0.255

 deny   ip any 70.185.0.0 0.0.255.255

 deny   ip any 200.106.176.0 0.0.7.255

 deny   ip any 200.106.184.0 0.0.1.255

 deny   ip any 206.184.246.0 0.0.0.255

 deny   ip any 208.134.161.0 0.0.0.255

 deny   ip host 39.105.128.242 any

 permit ip any any