KB ID 0000762 Dtd 26/02/13
For this procedure I was running an ASA5505 (Unlimited) with version 8.4(5). You will need to know the public IP address range allocated to you by BT (and the IP allocated to the router/hub).
Allocating a Public IP address to an Internal Client with the BT Business Hub
1. Log into the router, (the password initially is on the pull out plastic tab on top of the router). Set the IP to the one allocated to the router by BT (from the IP range they have given you). Note: The router actually gets a different IP address externally, this is normal, don’t panic.
2. Apply > Wait for the changes to apply.
3. Under business Network > Devices> You should see your device listed > Select it.
4. Assign the public IP as shown, you need to select the two radio buttons before the drop-down list of IP addresses will work > Apply.
5. Note: additionally if you are installing a firewall you might want to disable the Business Hubs internal firewall. Settings >Port Forwarding > Firewall > “Allow all traffic…” > Apply.
My firewall (after a reload) picked up the correct IP address, but was unable to connect to the internet. My laptop (also connected to the BT Business Hub) connected fine to the internet (both with an allocated public address, and using the public address of the router). The ASA could not get out at all, nor could it ping the IP address of the Business Hub. The ASA showed as disconnected for a while, then disappeared from the ‘Devices’ tab, even though it continued to get the correct IP address leased to it from the Business Hub, this persisted after a reload of the firewall – so the hub COULD see it. I tried giving the ASA the correct IP address statically, I also locked the speed and duplex of the ethernet interface (in case it was simply an auto-negotiation error), this did not resolve the problem. BT told me they had no record of anyone having the same problem, but that they would take a note in case it came up again. Luckily the client had his old 2Wire router as soon as I plugged that in everything worked fine. Â
Update 210414 (and resolution)
Got an email from Nate Morris this week who had been working on this very problem, while debugging the ARP traffic he saw;
arp-in: request at external from 192.168.1.254 c0ac.54e4.d8d8 for 188.8.131.52 0000.0000.0000 arp-in: Arp packet received from 192.168.1.254 which is in different subnet than the connected interface 184.108.40.206/255.255.255.248
This pointed to a known problem with Cisco ASA introduced in version 8.3(4). Cisco identified this as bug CSCty95468Â (Cisco CCO Login required to view). To resolve this problem you need to allow the ASA to populate its ARP table from a non connected subnet. To do this you need to issue an arp permit-nonconnected command.
User Access Verification Password: Type help or '?' for a list of available commands. Petes-ASA> enable Password: ******** Petes-ASA# configure terminal Petes-ASA(config)# arp permit-nonconnected Petes-ASA(config)# exit Petes-ASA# write mem Building configuration... Cryptochecksum: 28790e0e 91da681e 7cf92e8a 85efb7ea 9449 bytes copied in 1.310 secs (9449 bytes/sec) [OK] Petes-ASA#
Got an Email from Andrew Joubert, to say that he had the same problem, and he was using the BT business hub via BT Infinity not ADSL.
Related Articles, References, Credits, or External Links
Original Article Written 26/02/13
Credit to: Nate Morris, for finding the resolution to the original problem.
Special thanks to Steve at BT, who rang me back on my mobile so I didn’t have wait in a queue, and then followed up afterwards to see what the outcome was, if I knew his surname I would publish it! He did a grand job, and does not get paid enough!
Also thanks to Chris at BT who pitched in and did as much as he could.