CSM with RADIUS traffic does not perform NAT from the VIP of the return traffic

[avosani]

Hi,
We are building a network for the balancing of a radius service using 6509 and CSM module (4.2.6).
We are using the CSM in bridging mode (L2) between the server vlan and the client vlan.
The service has some servers providing radius authentication (UDP/1812) and radius accounting (UDP/1813) services on a VIP.
It seems the CSM works well when distributing the load between the servers, and doing NAT SERVER (the destination IP changes from VIP to the server IP).
However, the return radius ACK from the radius server to the source does not get translated back, and so, the source gets ACK replies from an unknown server, instead of the VIP.
The traffic is of this kind:

[SRC] ->                                    [CSM]                                    -> [RADIUS]

Packet:    

SRC IP: SRC                                   SRC IP: SRC

DST IP: VIP                                     DST IP: RADIUS

SRC PORT: N (given number)           SRC PORT: N  

DST PORT: 1813                              DST PORT: 1813

And it works well.

The Ack packet is:

[RADIUS] ->                                    [CSM]                                    -> [SRC]

Packet:    

SRC IP: RADIUS                                   SRC IP: RADIUS

DST IP: SRC                                         DST IP: SRC

SRC PORT: 2813                                   SRC PORT: 2813

DST PORT: N (SAME AS BEFORE)         DST PORT: N (SAME AS BEFORE)

Unluckily, the packet does not get translated back, it should change src ip to the VIP address.

Any ideas why this happens?

An excerpt of the cfg follows

vlan 3 client
   ip address 1.1.1.30 255.255.255.192 alt 1.1.1.29 255.255.255.192
  alias 1.1.1.28 255.255.255.192
!
vlan 4 server
ip address 1.1.1.30 255.255.255.192 alt 1.1.1.29 255.255.255.192
!

serverfarm FARM
  nat server
  no nat client
  real 1.1.1.1
   inservice
  real 1.1.1.2
   inservice
  !

vserver SERVER
  virtual 1.1.1.4 udp 0 service per-packet
  serverfarm FARM
  persistent rebalance
  inservice

Tks,

Andrea

[rodrguti_2]

Hello Andrea,

The issue looks to be an asymmetric flow, I guess that the CSM is not the default gateway for this server right?, anyway, you can fix this problem by configuring a natpool and then applying this natpool under the serverfarm as nat client, for example:

natpool test 1.1.1.35 1.1.1.35 netmask 255.255.255.192

serverfarm FARM
  nat server
  nat client test < --------- HERE
  real 1.1.1.1
   inservice
  real 1.1.1.2
   inservice

This should do the trick

Rod

[avosani]

Rod,

the CSM is the L2-gateway of the servers (we are using a bridging configuration, for design specs, you can see the conf).

So, every packet should be intercepted from the CSM but the return traffic doesn't get changed on the source ip field.

Yes, I know we can use client nat, but that goes against the need to preserve source and destination ports, that is a requirement of the protocol. The return packets should just be changed on the src ip field, exactly as a load balancer should do (just hide the servers behind).

In the conf I even tried to map the vserver udp on all ports (all the traffic is udp), anyway nothing seems changing.

Is that a hw limit of the CSM? I checked all the manuals and find nothing on it.

Tks,

Andrea

[rodrguti_2]

Hi Andrea,

Using bridge mode there is no guarantee that the traffic will return to the CSM by its own, I am sure that in this case, the return traffic is bypassing the CSM.

Could you please collect a CSM portchannel capture?

In your example, you have vlan 3 as client and vlan 4 as the server vlan, in your 6500, how these 2 vlans are configured?

Is vlan 3 configured as layer 3 (SVI)? what about vlan 4?

Thanks!

Rod.

[stmccabe · Accepted solution]

Hello,

The CSM, when in bridge mode and doing server nat you require a catch all vserver for client side traffic (source mac address to return the flow to).. Also, I noticed you are missing a gateway under your server vlan.. This should be added.. Try the below configuration, which i validated in my lab..  Notice how I'm gatching traffic with two nat statements (client/server side flows).. This is a best practice.  I will look for the document on cco and post.  I believe this will provide you the result you are looking for..

     !
      vlan 999 client
       ip address 10.1.99.100 255.255.255.0
       gateway 10.1.99.1
     !
      vlan 99 server
       ip address 10.1.99.100 255.255.255.0
     !
      natpool TESTPOOL 10.1.99.101 10.1.99.101 netmask 255.255.255.0
     !
      probe PING icmp
     !
      real TEST35
       address 10.1.99.5
       inservice
     !
      serverfarm GW-NAT
       no nat server
       nat client TESTPOOL 
       real 10.1.99.1
        inservice
     !
      serverfarm MCCABE
       nat server
       no nat client
       real name TEST35 80
        inservice
     !
      vserver CATCHALL
       virtual 0.0.0.0 0.0.0.0 any
       vlan 99
       serverfarm GW-NAT
       persistent rebalance
       inservice
     !
      vserver test-35
       virtual 10.1.99.200 tcp www
       serverfarm MCCABE
       persistent rebalance
       inservice

[avosani]

Hi,

Thanks for the answers,

yes the two vlans are just switched on the catalyst, they enter into the routed process with the other layer-3 vlans.

The default gw of the servers is the csm (the alias ip). We are totally sure there is not an asymmetric routing, the vlan servers talk with other vlans only by being bridged by the CSM.

We tried a similar catch-all configuration in the past days, now we'll check your last configuration: our aim is not to lose "src port" infos when the ACK comes back from the server to the client. We saw that nat client/natpool work as a PAT.

The other problem we had with our original catch-all configuration (listed below) is that we can't have two of them for different vservers/serverfarms (VIP) on the same vlan. We'll check it and we'll let you know

Our "check-all"

natpool NAT_UDP 1.1.1.4 1.1.1.4 netmask 255.255.255.192

serverfarm EXT_UDP_NAT

  no nat server

  nat client NAT_UDP

  predictor forward

vserver EXT_UDP_ALBBE

  virtual 0.0.0.0 0.0.0.0 udp 0

  serverfarm EXT_UDP_NAT

  vlan 4

  persistent rebalance

  client 1.1.1.1 255.255.255.255

  client 1.1.1.2 255.255.255.255

  inservice

Andrea