Bypass NAT for single printer IP

[Jamie Joh]

Hi all,

I posted a while ago that we were having problems translating an IP for a printer (located here https://supportforums.cisco.com/message/4099013#4099013)

We still haven't been able to get it working and thought about another approach which is to leave the printer IP as a 10.100.x.x IP and instead set up the ASA to bypass the NAT for this IP so it doesn't get translated.

Is this possible and how would i go about doing it?

Many thanks

Jamie

[Jamie Joh]

Hi,

No unfortunately it didn't work.

I checked the xlate and its definitely translating the IPs. We currently have the printer connected outside the firewall with the proper IP of 10.100.104.20, 255.255.255.0 and 10.100.104.1 as the gateway, prints fine.

As soon as i connect it to the firewall, IP address 172.29.8.20, 255.255.248.0 and 172.29.8.1 as the gateway the prints just do not get through.

According to our council the print spoolers are on the IP address 172.23.60.73.

So frustrating!

Many thanks

[Jouni Forss]

Hi,

Since you have been switching the Printer with the IP address 10.100.104.20 directly to the network outside of the ASA and then moving it behind the ASA and doing NAT for the local IP address to 10.100.104.20 that could mean that some upstream router might have an ARP information that pairs IP address 10.100.104.20 to the MAC address of the actual printer.

When you move the Printer behind the ASA and use the NAT then the Printer would be visible to the upstream router with the MAC address of the ASA as the ASA is doing the NAT.

In other words the upstream router would have the Printer MAC address in the ARP table (IP/MAC address pair) and couldnt therefore pass the traffic onto the ASA.

I would suggest changing the IP address for the NAT to 10.100.104.21 for example or any other IP address that you can use from the range and then trying connections again.

If you are using the NAT configuration I suggested then these changes should be enough

Go under the "object" configuration mode and then remove the current "nat" command and enter a new one.

object network TSTC-Printing

no nat (inside,outside) static 10.100.104.20

nat (inside,outside) static 10.100.104.21

This would naturally mean the tests should be towards this new IP address. This should probably tell us if ARP is the problem (because you have had the printer directly with the NAT IP address on the network outside of ASA)

- Jouni

[Jamie Joh]

The weird thing is i gave a completely different printer the 10.100.104.20 address and plugged it outside the network and it worked fine so im thinking the mac address maybe ok, but as soon as i change that printers IP to 172.29.8.20 and put it behind the firewall.. nothing!

At a loss now as to what it could be, the ASA couldn't be blocking anything else could it? They've definetely said that the printers use port 9100.

Many thanks

[Jouni Forss]

Hi,

Well you could configure a traffic capture on the ASA I guess

access-list PRINTER-CAPTURE permit ip host 10.100.104.20 any

access-list PRINTER-CAPTURE permit ip any host 10.100.104.20

capture PRINTER-CAPTURE type raw-data access-list PRINTER-CAPTURE interface outside buffer 1000000

Then you should ask them to test the connection when the Printer is behind the ASA

Then you could use the following command to check if anything has hit the capture

show capture

If something has hit the capture you could use this command to show the contents of the capture on the CLI

show capture PRINTER-CAPTURE

These should tell us if the traffic from the testers is arriving to the ASA

- Jouni

[Jamie Joh]

Ok i just plugged in the 172.29 printer behind the firewall, did a test print which failed, did the printer capture and its coming up with the following:

3 packets captured

   1: 04:58:38.515277 10.100.104.20.138 > 255.255.255.255.138:  udp 201

   2: 05:01:09.341870 10.100.104.2.56538 > 10.100.104.20.161:  udp 78

   3: 05:01:09.345105 10.100.104.20.161 > 10.100.104.2.56538:  udp 81

3 packets shown

Many thanks

[Jouni Forss]

Hi,

The first capture UDP packet is a broadcast related to some Windows service. It wont go through the firewall.

The second 2 UDP packets are SNMP traffic back and forth from the Printer.

No traffic related to the ports you mentioned.

I am not sure of all the roles of the ports that Windows uses but could the broadcast message from the host 10.100.104.138 be related to the test?

It seems though that the SNMP traffic is both ways but I dont see anything else there other than the broadcast that might be unrelated also.

- Jouni

[Jouni Forss]

Also,

I presume you had the capture configured BEFORE you did any tests?

- Jouni

[Jamie Joh]

Yes i configured the capture, then did a test print, then did a show capture.

I've since put the 10.100.104.20 printer back outside of the firewall and did another capture, seems to still be getting some hits.

4: 05:10:41.985926 10.100.104.20.138 > 255.255.255.255.138:  udp 201

   5: 05:10:41.987131 10.100.104.20.137 > 255.255.255.255.137:  udp 68

   6: 05:10:42.219394 10.100.104.20.137 > 255.255.255.255.137:  udp 68

   7: 05:10:42.488835 10.100.104.20.137 > 255.255.255.255.137:  udp 68

   8: 05:11:09.450767 10.100.104.2.56538 > 10.100.104.20.161:  udp 78

   9: 05:11:09.454245 10.100.104.20.161 > 10.100.104.2.56538:  udp 81

  10: 05:14:41.004836 10.100.104.20.138 > 255.255.255.255.138:  udp 201

  11: 05:19:39.758673 10.100.104.20.138 > 255.255.255.255.138:  udp 201

  12: 05:21:08.559571 10.100.104.2.56538 > 10.100.104.20.161:  udp 78

  13: 05:21:08.563828 10.100.104.20.161 > 10.100.104.2.56538:  udp 81

13 packets shown

I believe SNMP may be disabled on the councils end but like i say it still seems to print fine when not behind the ASA.

Many thanks

[Jouni Forss]

Hi,

I actually managed to read the capture wong since it lists the ports right after the IP address. There is no IP address 10.100.104.138 as it was actually 10.100.104.20.138

Actually now that I look at it closer, it seems to me that there is traffic from behind the "inside" interface of your ASA towards that destination IP address?

   8: 05:11:09.450767 10.100.104.2.56538 > 10.100.104.20.161:  udp 78

   9: 05:11:09.454245 10.100.104.20.161 > 10.100.104.2.56538:  udp 81

  12: 05:21:08.559571 10.100.104.2.56538 > 10.100.104.20.161:  udp 78

And this traffic is birectional and not broadcast. The IP address 10.100.104.2 is your "outside" interface IP address with which ALL your internal hosts show up to the hosts behind the "outside" interface.

If you had taken the Printer of the "outside" network when this traffic was captured then it would seem to me that there is a device behind the "outside" interface with the IP address 10.100.104.20 already?

These packets in the capture would seem to point that there was still a device with IP address 10.100.104.20 in the network when that capture was taken

   4: 05:10:41.985926 10.100.104.20.138 > 255.255.255.255.138:  udp 201

   5: 05:10:41.987131 10.100.104.20.137 > 255.255.255.255.137:  udp 68

   6: 05:10:42.219394 10.100.104.20.137 > 255.255.255.255.137:  udp 68

   7: 05:10:42.488835 10.100.104.20.137 > 255.255.255.255.137:  udp 68

  10: 05:14:41.004836 10.100.104.20.138 > 255.255.255.255.138:  udp 201

  11: 05:19:39.758673 10.100.104.20.138 > 255.255.255.255.138:  udp 201

This is because we see a broadcast on the ASA to destination address 255.255.255.255 from the IP address 10.100.104.20

When the Printer is behind the "inside" interface can you do so that you clear the ARP on the ASA with the command "clear arp" and then send ICMP to the IP address 10.100.104.20 with the command "ping 10.100.104.20" and then view the arp with "show arp | inc 10.100.104.20" command.

It should show if there is a device behind the "outside" interface that is already using that IP address.

- Jouni

[Jamie Joh]

Ok will run that command in a second. Clearing the ARP won't have any affect on users currently logged in and using the internet will it?

Many thanks

[Jouni Forss]

Hi,

To my understanding clearing the ARP should not cause any problems. The ASA should send ARP request for the destination IP addresses right after clearing  the ARP.

- Jouni

[Jamie Joh]

Ok, ive cleared the ARP, there is now no answer from the ping so it should be clear. Should i try a print again or is there something else i can do on the ASA?

Many thanks

[Jouni Forss]

Hi,

Did you take the output of "show arp | inc 10.100.104.20" after your cleared the ARP and pinged that destination IP address? That was what I was after. The device might not reply to ICMP but it will answer to ARP requests. (If there is another device in the network with that IP address)

- Jouni

[Jamie Joh]

Yep nothing is appearing after doing the show arp command.

[Jouni Forss]

Hi,

If the configuration was as suggested when the device was behind the ASA and the traffic was allowed then it doesnt seem like a problem with the ASA.

There seems to be something else wrong but I am not sure what. I dont know what the actual topology of the network is.

There should be nothing different with the Printer being NATed to the IP address towards the network segment that holds this subnet 10.100.104.0/21 or having the device directly in that network segment together with the ASA. If there is something perhaps related to broadcast traffic (which would mean users of the Printer would be in the same network 10.100.104.0/21) then that naturally stops at the ASA but not in the situation when the Printer is directly connected to the network 10.100.104.0/24

I don't know how much else can be determined from the ASA itself anymore.

We didnt see the traffic on the ASA with the capture that we were expecting and we dont know what is different in the situation when the printer is directly in the network. Unless ofcourse you capture that traffic from some switch to which the printer is connected when its outside the ASA.

- Jouni