5

Here is the background info:

I support a legacy regional group of users with trunk mounted cellular data modems. These devices use a private APN, meaning they do not communicate directly over the Internet, all traffic from these devices come from the wireless provider into our private network over a leased line, at which point the firewall decides to discard or route the packet.

The vendor who provided this private APN setup a long time ago used public addresses for the mobile devices as well as a specific public subnet that they could communicate with. For illustration purposes, I'll say the subnet was 1.2.3.0/29 (this is not the real subnet). So we could address 6 devices on our network (1.2.3.1 - 1.2.3.6).

The device provides connectivity for laptops in the vehicle, but also each also reports AVL location data to one of these servers, lets say that is 1.2.3.6. These reports are UDP messages on a well known port, let's say that is port 21000. The device configuration requires an IP Address, not a DNS queryable device name.

No server on our private network actually has the address 1.2.3.6. The Cisco ASA Firewall has a UDP PORT NAT for port 21000 from any machine in the public subnet that the mobile units use to the real address of the AVL server.

Change is coming: Now, so many years later, we are upgrading capabilities, and the devices will now be assigned private addresses by the wireless vendor. The public subnet for the mobile devices, as well as the public subnet for our servers (1.2.3.0/248 above) will no longer be assigned to us once the migration is complete. So then the 1.2.3.6 address that we've been using for AVL will no longer "belong" or otherwise be assigned to us (It's always belonged to the vendor).

The problem: The new private subnet the mobile devices will now get addresses in is not included in the UDP PORT NAT firewall rule. Once we migrate the APN, then, the cellular modem will no longer be able to report their AVL location successfully. The cellular modems (over 1000 of them) must be manually reconfigured one at a time if we change the AVL server address. If we move forward with the migration, the AVL reports will stop working until we manually reconfigure each modem. If we reconfigure before the migration, we break AVL until the migration occurs. There is no way to automate making these changes concurrently.

My Solution: I first asked my network vendor to add the new 10.x.x.x subnet for mobile devices to the firewall rule that port forwards UDP to 1.2.3.6 port 21000 to the proper server. I was told I cannot NAT traffic from a private (10.x.x.x) address that is attempting to reach a public address (1.2.3.6) to an internal server. I don't know if this is a safety violation the Cisco ASA will not allow, or if this is a policy of the network vendor. I then asked if perhaps the router before the firewall could do this UDP PORT NAT for me, changing 1.2.3.6 to the server's "real" address before the traffic reaches the firewall. No, I was told that since we will no longer be assigned this one particular public address, he cannot include that UDP PORT NAT in the router. "we cannot hang on to a block assignment we do not lease or own."

My Question: Perhaps this is a matter of opinion? Only traffic coming in on our leased line (which is just the mobile devices) would even have access to this one very specific rule. They certainly would never need nor try to access a public Internet device at 1.2.3.6 port 21000. Are there risks I am not aware of? I understand the situation is not ideal, but I am trying to find a solution that would allow us to move forward with the newer faster APN technology but not break every modem configuration in the fleet.

Am I asking the vendor to do something that legitimately should not be done? I don't wish to cause any security risks, or try to use or steal public address space not allocated to me. What would you do to support this network challenge?

  • There mistype. mask mut be 29 - 1.2.3.0/29 – mmv-ru Dec 27 '14 at 14:43
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 11 '17 at 2:25
3

If I'm reading this correctly, the bottom line is a need to hairpin traffic at the ASA? On the old Pix, that's not possible -- traffic cannot enter and leave the same interface. On the ASA (somewhere in the 7.x line) same-security-traffic permit intra-interface came about to allow hairpinning.

object-group network Private-Addresses
 network-object 10.0.0.0 255.0.0.0
 network-object 172.16.0.0 255.240.0.0
 network-object 192.168.0.0 255.255.0.0

nat (inside,inside) source dynamic Private-Addresses interface \
    destination static [PUBLIC-ADDRESS-OBJECT][[PRIVATE-ADDRESS-OBJECT]

This link on Cisco's support forum may be of great use to you. What you need is a "nat (inside,inside)" rule.

(Of course, the correct path is to fix the software... stop hard coding an IP into software where it cannot be changed. Numerous vendors have been bitten on the ass with that one -- builtin ntp server addresses. This is also a lessen in not assuming currently "unused" space is yours to do with as you please.)

  • Will this work for a single port? I am not sure what that is called in an ASA... Something similar to simply ip nat inside source static udp 10.2.3.6 80 1.2.3.6 21000 extendable – Brian B Jan 7 '15 at 14:58
  • Depends on the ASA version (8.3+ completely buggered up the NAT language) I'm not clear on how NAT interacts with a hairpin. (On IOS, one must jump through hoops as NAT won't do anything intra-interface.) – Ricky Beam Jan 7 '15 at 21:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.