VTC NAT problem

[nwallette]

I'm having a problem getting a standalone VTC box working.  We're replacing Cisco ASAs with PA-500s at our sites, so there are existing rules that should be working when translated to Palo Alto.  I'm fairly confident I have the requirements down:

tcp/1720 (h323)

tcp/5060 (sip)

tcp/5061 (sip-tls)

udp/5060 (sip-udp)

tcp/60000-64999 (media-tcp)

udp/60000-64999 (media-udp)

We have the VTC box in the site DMZ, with the outside IP translated like so:

Src Z: Outside

Dst Z: Outside

Dst If: any

Src IP: any

Dst IP: 1.1.1.1 (our fake public IP)

Svc: any

Dst Translation: 10.1.1.10 (our fake VTC internal IP)

...and the relevant ACL:

Src Z: Outside

Dst Z: DMZ

Src IP: any

Src User: any

Dst IP: 1.1.1.1

App: any

Svc: Service Group "vtc" (contains the services named above)

Action: Allow

There's another ACL to allow Src Z: DMZ to Dst Z: Outside on any traffic.

Now here's what happens:

- Using the famous VTC Callback test site (71.14.2.158), the call connects, but there's no audio/video.  This usually means the UDP/TCP media ports aren't being allowed in.

- From outside, connecting to 1.1.1.1 on tcp/1720 succeeds.  I've tested with another outside VTC, and with telnet 1.1.1.1 1720.  No audio/video, though.

- Using the debug dataplane packet-diag series of commands to log rx, tx, firewall, and drop to separate pcap files, I see in the firewall capture all of the call setup stuff.  Looks good.  However, in the drop log, I see the incoming UDP packets to port 60232 (for example) being dropped.

So, I don't see why incoming on tcp/1720 works, but using the same rule to allow UDP on 60,000 - 64,999 would drop packets to 60,232.

[rmonvon]

Hi...Can you test and allow all service ports on the security rule (i.e. ACL) instead of limiting it to Svc: Service Group "vtc".  Thanks.

[nwallette]

I think I see the problem.  I'm only doing destination translation, so outbound calls are still originating from the NAT overload IP.  In this case, UDP reply packets are being dropped because they're not going to the public translated IP reserved for the VTC box, but rather, the outside interface IP, which has no allow rule.

I think by using bi-directional source NAT, I can fix this.  Will try and update the ticket when I have someone on-site to test the changes.

[nwallette]

Nope, I got further, but I'm still having trouble with this.  I suspect I know what's wrong now.  Can someone confirm is this is correct?

Outside interface IP is 1.1.1.1.

VTC public IP is 1.1.1.2.

VTC internal IP is 10.1.1.10.

Zones are "Outside", and "DMZ".

I have a NAT rule like so:

Zone Src:  DMZ

Zone Dst:  Outside

IP Src:  10.1.1.10

Translate Src:  static-ip 1.1.1.2, bi-directional yes

BELOW that is the Overload rule, all zones source translation of dynamic IP and port, using interface IP.

As I understand, the above should guarantee:

- Outbound connections from 10.1.1.10 originate from 1.1.1.2, not the outside interface default IP.

- Inbound connections to 1.1.1.2 should be translated to 10.1.1.10.

So far so good?

Now, my ACL:

Zone Src:  Outside

Zone Dst:  DMZ  (Edit: Outside)

IP Dst:  1.1.1.2

Svc:  VTC (tcp 1720, tcp/udp 5060, tcp/udp 60000-65000)

Action:  Allow

Now my question:

- Does this do inspection by nature of the protocol?  Or do I need to use the "Application" field to enable packet inspection and payload address translation?

[rmonvon]

Your NAT rule is correct and the bi-directional NAT will ensure inbound & outbound traffic to use the same IPs, 10.1.1.10 <--> 1.1.1.2.

Your security rule (ACL) need the dest zone=DMZ.  Previously, you had the dest zone=DMZ and you should keep this.

Zone Src:  Outside

Zone Dst:  DMZ.

IP Dst:  1.1.1.2

Svc:  VTC (tcp 1720, tcp/udp 5060, tcp/udp 60000-65000)

Action:  Allow

Since you didn't mention the setting for application, I assume you left application=any.  In that case, the PA firewall will scan the traffic on those VTC ports and identity the applications.  Thanks.

[nwallette]

My mistake -- the security rule destination zone is indeed DMZ.  I've edited my post to reflect this.

Yes, I'm leaving the Application field to Any.  So, this should be doing inspection of ALL traffic and modifying the payload addresses of packets with known protocols?  I'm wondering if this is actually being done.  I set up a packet capture on the firewall for all stages.  In the Transmit stage, my capture file shows this:

Source:  1.1.1.2;  Destination:  71.14.2.158  (VTC Test);  Protocol:  TCP;  Port:  62185 > h323hostcall (1720)

H.225.0 CS > H323-UserInformation > h323-uu-pdu > h323-message-body: setup > setup > sourceAddress > Item 0 > AliasAddress: transportID > transportID: ipAddress > ipAddress = 10.1.1.10; port 1720

The inside IP also shows up in another field in the same packet.  I would've expected, on a packet transmitted from the public IP to the VTC Test site, to see this address being re-written as the public IP if packet inspection were working.  Maybe I'm looking in the wrong place..

FWIW, NAT (awareness) mode is turned OFF on the VTC, which (as I understand it) is correct when the firewall will be inspecting and rewriting packets as necessary.  On the recently-replaced ASA, this arrangement was functional, so I think the VTC config is OK.

[rmonvon]

Depending on the application and its manufacturer, we may not rewrite the IP address in the payload.  Can you test with NAT awareness enabled on your VTC gear please.

If that does not work, please contact support to investigate in more details.  Thanks.