Return UDP packets of a bidirectional UDP "flow" have source port changed

hokiemarkle · ‎03-19-2008

Hello,

We (Aspera) are an application vendor and our application uses UDP. We have a customer with a Cisco CSS 11503 device and it looks like that device is altering the UDP source port of UDP packets as they flow back out the CSS device.

A _simplified_ description of their environment is that the customer has a Cisco CSS 11503 between a Win 2K server in the data center and a client machine on the internet. Let's pretend that the external address of their server is 200.100.50.25 and the internal address is 172.16.50.25...

Our application's UDP traffic is bi-directional. Typically a UDP packet to the server elicits a UDP response back to the client. What we see is that on the UDP

Client sends UDP to server as (traced on client machine):

08:25:02.xxxxxx colo.asperasoft.com.50568 > 200.100.50.25.33001: udp 978 (DF)

Internal server sees (traced on server machine):

08:25:02.xxxxxx colo.asperasoft.com.50568 > 172.16.50.25.33001: udp 978 (DF)

So far so good... That packet it made it through as expected... Src/dest IPs and ports are as we'd expect and the ports are unchanged from what the client sent.

Internal server sends (trace captured on internal side of CSS 11503):

08:25:02.xxxxxx 172.16.50.25.33001 > colo.asperasoft.com.50568: udp 92 (DF)

All still looks good... UDP ports are reversed as one would expect in the reverse direction...

Client sees (captured on external [egress] side of CSS 11503):

08:25:02.xxxxxx 200.100.50.25.2056 > colo.asperasoft.com.50568: udp 92 (DF)

You can see that the return UDP packet has had its source changed/mapped/translated/whatever... Since all looked well going into the CSS and this shows the port changed on egress from the CSS, it looks like the CSS is altering the source port on this returned UDP packet. Our client app (for better or for worse) is expecting the source port on the returned packet to be the same as it was sent to (33001).

I don't have the specifics of the customer's CSS config info related to this, but I can get that. Does anyone have an idea of what might be happening here and waht configuration stuff we can have the customer consider trying that might rectify this?

Thanks in advance...

Chris

Gilles Dufour · ‎03-20-2008

The CSS is most probably configured with a 'group' to nat the response from the server so they all appear to come from a single vip.

By default this nating modifies the source port of udp packets.

This can be disabled with the command 'portmap disable' under the group configuration.

Gilles.