We're trying to publish a vpn server (PIX 501) with our ISA 2004 firewall.
The WAN ip of the ISA box is 64.146.x.y, and provides our connectivity.
The LAN ip of the ISA box is 10.128.0.1/16
The 'outside' (or LAN) ip of the PIX 501 is 10.128.0.4/16 with a default gateway of 10.128.0.1
The PIX's 'WAN' port connects to the ISA's 'LAN' port via a switch.
The ISA 2004 box is not involved in the VPN tunnel except to pass the UDP packets on ports 500 and 4500 (and perhaps 50, others).
We're having trouble getting the tunnel to come up (Nat traverasal is enabled on the Pix), and we notice that when the pix sends a packet to the VPN peer with both source and destination ports set t o 500, that the ISA 2004 box rewrites the source port to something like 62247 or 18396 or any number of other seemingly random high ports.
ISA is doing what it's supposed to and this behavior is allowed by the RFC - what device are you connecting to that doesn't like this? (I'm implying that the remote peer can't handle the change in source address being the cause for your question).
To answer your question directly - there is no way to control/change the source port that ISA uses when it NATs this traffic.
Some VPN protocols were first specified as using the same port 500 or 4500 for both source and destination port. Later, when natting became popular, VPN manufacturers began working in support for rewritten source ports.
Incidently, we're dealing with a remote endpoint that doesn't know how to deal with rewritten source ports coming from the initiating (local) endpoint.
For the short term solution, we just stuck in a linux/iptables solution, which, for some reason beyond me, does not seem to be rewriting the ports, and the tunnel works fine. But we would like to move this back to the ISA 2004.
And here's the weird part: At one time, last week, I was trying different thingson the ISA 2004 box, and ISA 2004 was sending out the packets without rewriting the source ports. At least I beleive that to be the case, but I can go check a tcpdump log to verify it. But that was before we'd enabled nat traversal on the pix -- so even though ISA was working, the pix wasn't happy. Now that the PIX is configured for NAT, ISA won't comply.
I just realized that I didn't answer your question.
What device can't handle this? I don't know what device, but it's a VPN endpoint at Siemens Uptime Center. And you are correct -- it should be able to handle it, but it doesn't seem to be able, and we wish to connect to it anyway.
What puzzles me is that earlier last week or so, before we had NAT Traversal enabled on our pix, I did witness the ISA 2004 box natting UDP packets without rewriting the ports (any of them.) If you doubt that, then I may have been confused/wrong and will be glad to go check my log and see. (I saved it.)
I checked my packet capture log, and verified that ISA 2004 had indeed, at one time not long ago, been NATTing packets without rewriting and port numbers. It's very clear; The mac address (Source and Dest) of each packet are recorded with each packet, so I know it was the ISA 2004 box doing this.
I was not doing anything with routing rules, but we did at one time, have partly enabled some unused VPN rule which was supposed to cause the ISA 2004 box act as a vpn endpoint. That rule was swollowing UDP 4500 packets that should have been forwarded in passthrough style, so we turned off that rule since we were not using it.
I guess it's possible that that vpn rule (not firewall rule) might have somehow caused passed through/natted packets to not have their ports rewritten.
Or perhaps it was because we were forwarding ports 500 and 4500 from the outside into the pix 501 -- maybe when the port UDP 500/4500 connection was initiated from the outside first, the ports were not rewritten.
If you have any interest in seeing the packet by packet log (4 long lines of plain text) of the nat happening without port changing, I'd be glad to email it to you.