Answering my own question to help future googlers. I spent about 3 hours on the phone with TAC; we finally got to the root cause of the issue.
The solution is to add a special NAT entry, which matches the IP address in the DNS A-Record when it arrives on the INSIDE interface.
object network DNS_NAT_masd1
description xlate A-Record DMZ src 1.195.18.182 to INSIDE src 10.195.18.182
host 1.195.18.182
nat (DMZ,INSIDE) static 10.195.18.182
When I asked for a pointer to documentation that describes why DNS translation works this way, the TAC lead said that he didn't know of any that described this behavior. The TAC lead also mentioned that with more code, the ASA would know to automatically translate the DNS A-Record without explicitly adding object network DNS_NAT_masd1
; however, that is not how the dns
keyword for ASA NAT works today. For reasons that still are not completely clear yet, the ASA requires the DNS A-Record IP to match the <proxy_addr>
in the NAT statement, using syntax similar to this...
object network obj-EXAMPLE
description NAT object explicitly for translating DNS A-Records
host <proxy_addr>
nat (<REAL_INTF>,<PROXY_INTF>) static <real_addr> dns
The difficulty is that this configuration is exactly backwards for what you need to do if you're going to nat regular "data plane" IP traffic through the firewall.
This is the whole configuration that works...
object network DMZ_NAT_masd1
host 10.195.18.182
description xlate masd1 NAT DMZ src 10.195.18.182 to INSIDE src 192.168.11.101
object network INSIDE_NAT_masd1
host 10.195.18.182
description xlate masd1 NAT INSIDE src 10.195.18.182 to DMZ src 1.195.18.182
!!! DNS_NAT_masd1 is new
object network DNS_NAT_masd1
host 1.195.18.182
description xlate A-Record DMZ src 1.195.18.182 to INSIDE src 10.195.18.182
!
object network DMZ_NAT_masd1
nat (DMZ,INSIDE) static 192.168.11.101
object network INSIDE_NAT_masd1
nat (INSIDE,DMZ) static 1.195.18.182
!!! DNS_NAT_masd1 is new
object network DNS_NAT_masd1
nat (DMZ,INSIDE) static 10.195.18.182 dns
You have a few options, two of which in particular come to mine.
Solution 1
Many times, when a Vendor says "no NAT is allowed", they really mean "no PAT is allowed". This is typically because of a PAT being, by definition, unidirectional. In most VPN type systems, both peers need to be able to initiate traffic to the other, which isn't possible in a unidirectional communication system, like PAT.
As such, the solution is to give your Checkpoint Firewall a Private address, say 192.168.1.25. Then create a Static NAT on your ASA to translate 192.168.1.25 to one of the IPs in the additional /30 your ISP has assigned.
From the VPN configuration perspective, the remote end will use the Public /30 address as their "opposing peer", and you will use the other end's IP address as your "opposing peer". Then, as long as NAT Traversal is enabled (which it typically is by default, but I can only confirm that on the Cisco ASA), the VPN tunnel should be able to build through the Static NAT.
This is your ideal solution, I would suggest going this route if you can. Mainly, because you are holding in reserve the other 3 IPs of the 4 they gave you in the /30. But, if you see no use for these, now or in the future, Solution 2 might work out for you:
Solution 2
Use the /30 assigned by your ISP as its own "transit" network between the ASA and Checkpoint. You'll need an additional interface on the ASA, or you could have the same effect with a Trunk configuration. The ASA will have two segments off it, the transit network, and the DMZ network. Then your "inside" network will simply be "behind" the Checkpoint.
I was going to try to explain this with text, but I figured a picture was easier. I made up the IPs, since you didn't provide them:
You could either use Identity NAT on the ASA to allow the traffic through un-natted, or simply configure a NAT Exemption for the /30 network.
All other options beyond this require a bit of creativity, but are probably considered non-standard, and as such should be avoided unless the solutions above don't work. If they don't, please provide specific details as to why, so we can try to provide additional solutions.
Best Answer
Back on the stage :) One small and unimportant detail: according to Cisco, one model of 2960 is Layer 3 capable - 2960XR.
Speaking about your possible configuration, it woud be nice to have two additional switches (vlan capable, not dumbs). I'd use 4 interfaces: "outside", "inside", "DMZ" and "wifi".
"Outside" link goes to your ISP;
"DMZ" - to the DMZ switch with the servers;
"WIFI" connects to the additional wifi network switch. Here you define subinterfaces for 2 wifi vlans. On the switch side corresponding port should be in dot1q trunk mode. Probably you'd need WIFI AP to be in trunk mode too.
"Inside" goes to the second additional switch, which is connecting your internal subnets; define here subinterfaces for the subnets and put switch's port into trunk mode.
One example of such configuration (alas, without the switches): https://www.speaknetworks.com/cisco-asa-dmz-configuration-example/