Source-group fails to provide source address translation

[scott.dunn]

Can anyone see what is wrong with my source-group, “skylar”?

I am trying to use it to do a source address translation from the real address: 172.24.0.58 to the virtual address 172.24.1.72.

The real host, 172.24.0.58 is connected directly to the css, on port 3/9 (vlan 3). All routing, etc, is fine, since I can get out and about from the host; the problem is simply that the source address is not translated as it goes.

The default gateway of the real host is: 172.24.0.33, which is a redundant interface provided by the virtual-router on this css (since I am directly connected to the css which is active for all redundant resources, the second css is effectively not even there).

Here is the config:

sh run

!Generated on 10/29/2004 14:33:03

!Active version: sg0720206

configure

!*************************** GLOBAL ***************************

bridge priority 100

setspan src_port 3/4 dest_port 3/6 copyBoth

ip route 0.0.0.0 0.0.0.0 172.24.1.65 1

!************************* INTERFACE *************************

interface 3/1

phy 100Mbits-FD

description "< uplink to Primary Pix, e2 >"

interface 3/2

description "< 802.1q trunk to CSS-2 >"

phy 100Mbits-FD

trunk

vlan 1

default-vlan

vlan 2

vlan 3

interface 3/3

description "< 802.1q trunk to CSS-2, b/u >"

phy 100Mbits-FD

trunk

vlan 1

default-vlan

vlan 2

vlan 3

interface 3/4

phy 100Mbits-FD

description " "

interface 3/5

description "< vlan 2 >"

phy 100Mbits-FD

bridge vlan 2

interface 3/6

description "< vlan 2 >"

phy 100Mbits-FD

bridge vlan 2

interface 3/7

description "< vlan 3 >"

phy 100Mbits-FD

bridge vlan 3

interface 3/8

phy 100Mbits-FD

description "< laptop, vlan 1 >"

bridge vlan 3

interface 3/9

description "< temp skylar >"

phy 100Mbits-FD

bridge vlan 3

interface 3/15

description "< isc port 1 >"

isc-port-one

phy 100Mbits-FD

interface 3/16

description "< isc backup port >"

isc-port-two

phy 100Mbits-FD

!************************** CIRCUIT **************************

circuit VLAN1

ip address 172.24.1.69 255.255.255.240

ip virtual-router 1 priority 105 preempt

ip virtual-router 11 priority 105 preempt

ip redundant-interface 1 172.24.1.68

ip redundant-vip 11 172.24.1.71

circuit VLAN2

ip address 172.24.0.5 255.255.255.224

ip virtual-router 2 priority 105 preempt

ip redundant-interface 2 172.24.0.3

circuit VLAN3

ip address 172.24.0.35 255.255.255.224

ip virtual-router 3 priority 105 preempt

ip redundant-interface 3 172.24.0.33

!************************** SERVICE **************************

service app-2950-1

ip address 172.24.0.69

active

service app-2950-2

ip address 172.24.0.68

active

service skylar

ip address 172.24.0.58

active

!*************************** OWNER ***************************

owner GiftCard-N1-LAB

content app-2950

vip address 172.24.1.71

add service app-2950-1

add service app-2950-2

protocol tcp

port 23

content skylar

vip address 172.24.1.72

add service skylar

active

!*************************** GROUP ***************************

group app-2950

vip address 172.24.1.71

add destination service app-2950-1

add destination service app-2950-2

active

group skylar

vip address 172.24.1.72

add destination service skylar

active

css-1-gc-N1-LAB#

[seilsz]

Under 'group skylar', change:

add destination service skylar

to:

add service skylar

~Zach

[scott.dunn]

Zack,

Thank you, that did work; but I'm no less confused. Please look at the following paste. The first config you saw was from the lab.

The following paste (greatly trimmed) is from the production equivalent. I've removed everything except the lines supporting the direct-ssl-xml-app.

Please note that this configuration results in translation of the source addresses of the three service hosts to 172.24.0.44. Can you explain it?

Scott

sh run

!Generated on 10/29/2004 21:41:19

!Active version: sg0720206

configure

!*************************** GLOBAL ***************************

!************************* INTERFACE *************************

!************************** CIRCUIT **************************

!************************** SERVICE **************************

service eos24r-direct-ssl-xml-app

ip address 172.24.0.86

port 7443

redundant-index 61

keepalive type script gc-app-keepalive "172.24.0.86 eos24r"

active

service eos25r-direct-ssl-xml-app

ip address 172.24.0.89

port 7443

redundant-index 62

keepalive type script gc-app-keepalive "172.24.0.89 eos25r"

active

service eos26r-direct-ssl-xml-app

ip address 172.24.0.92

port 7443

redundant-index 63

keepalive type script gc-app-keepalive "172.24.0.92 eos26r"

active

!*************************** OWNER ***************************

owner GiftCard.sdf

content direct-ssl-xml-app

vip address 172.24.0.44

protocol tcp

port 7443

redundant-index 60

add service eos24r-direct-ssl-xml-app

add service eos25r-direct-ssl-xml-app

add service eos26r-direct-ssl-xml-app

active

!*************************** GROUP ***************************

group direct-ssl-xml-app

vip address 172.24.0.44

redundant-index 64

add destination service eos24r-direct-ssl-xml-app

add destination service eos25r-direct-ssl-xml-app

add destination service eos26r-direct-ssl-xml-app

active

css-1-gc.sdf#

[seilsz]

Are you saying that the source address is translated when you initiate the connection from the real servers? Or that the source address is translated when the real servers respond to a connection initiated from the client side?

Can you attach a copy of the output from a 'sh flows 0.0.0.0'?

~Zach

[scott.dunn]

Oh, I’m sorry. It’s been a while since I built all this, and I was remembering an important detail wrong.

The source address translation that configuration performs is NOT from servers behind the CSS, rather the translated source address is the incoming customer source address. The customer targets a VIP created on the CSS and the CSS translates the customer source address and load balances across three servers that are not reached through the CSS.

Because of the topology, without the source address translation, the return packets would go straight back to the customer, bypassing the CSS. The CSS translates the source address in order to bring the responses from the servers back to itself, NOT to local servers behind it.

That explains the difference.

So my new requirement is different. But I think the information that you provided in your first response is the technique I need to get two real servers that are behind the CSS to open connections out to a customer, with the customer seeing both these servers as a single address with multiple sockets.

Once the outgoing connections to the customer are established, the customer can submit transactions over any of the opened sockets. Then a backend process is initiated wherein the same two servers open connections as needed (one per submitted transaction) to other servers at our site that provide backend processes. It would be preferable that those backend transactions were NOT source address translated. It is these backend processes that are load balanced by the CSS.

I’m going to need to think about that. When the two servers that open connections to the customer, open the connection to the customer, source address translation is needed. But when those same two servers open connections for their back end processes, they should NOT be source address translated (just to make transaction logs easier to read).

I’m guessing I can do a source address translation, or not, depending on the source port, and that the application may use different source port ranges, depending on whether it’s opening a customer facing process or a backend process.

Any thoughts?

[seilsz]

You can use source groups in conjunction with an ACL to determine what traffic gets translated. You can find more information here:

http://www.cisco.com/en/US/partner/products/hw/contnetw/ps792/products_configuration_guide_chapter09186a008029cab6.html#wp1150203

If you can provide some source and destination IP addresses, I wouldn't mind helping you work through a config.

~Zach

[scott.dunn]

The two servers behind the css (on vlan 3) are called ut servers. I'm going to give you made up ip addresses, on general principles. These are the servers that need source address translation when going to custservers, and need NOT translation when going to backend servers. For the source translation you can use 192.168.10.10.

ut-1 = 192.168.1.50 /24

ut-2 = 192.168.1.51 /24

Customer address:

custserver1 = 10.1.1.50 /24

custserver2 = 10.1.1.51 /24

The backend process server ip addresses are:

backend1 = 172.16.1.50 /24

backend2 = 172.16.1.51 /24

backend3 = 172.16.1.52 /24

Your help is above and beyond; thank you.

[seilsz · Accepted solution]

Ok ...

--!create a source group for nat

group HIDEME

vip address 192.168.10.10

active

--!create an acl

acl 10

!--exclude ut --> backend traffic from NAT

clause 1 bypass any 192.168.1.0 255.255.255.0 destination 172.16.1.0 255.255.255.0

!--Translate ut --> anything else

clause 2 permit any 192.168.1.0 255.255.255.0 destination any sourcegroup HIDEME

!--apply acl to vlan3

apply circuit-(VLAN3)

~Zach

[scott.dunn]

That's a different ACL syntax, |:o).

[scott.dunn]

I tried the ACL technique you provided in order to prevent source address translation when going to a certain destination address. I haven’t been able to get the ACL to exclude source address translation as expected. Can you see anything wrong in the way I’ve applied it?

I’m back in the lab with this, so the full configuration given above is still valid. I’ve included below a few relevant pieces from the above config, and also you can see the ACL in this snippet.

Objective:

The source address to be conditionally nat’ted is 172.24.0.58.

It is to be translated when making a connection to 172.24.1.65, and NOT to be translated when connecting to 12.223.2.8

(note that this is entirely within the lab; thus the 12.space address does not refer to its true owner on the Internet)

I am seeing source address translation to both destinations, as if the ACL were not there.

!************************** CIRCUIT **************************

circuit VLAN3

ip address 172.24.0.35 255.255.255.224

ip virtual-router 3 priority 105 preempt

ip redundant-interface 3 172.24.0.33

!************************** SERVICE **************************

service skylar

ip address 172.24.0.58

active

!*************************** OWNER ***************************

owner GiftCard-N1-LAB

content skylar

vip address 172.24.1.72

add service skylar

active

!*************************** GROUP ***************************

group skylar

vip address 172.24.1.72

add service skylar

active

!**************************** ACL ****************************

acl 10

clause 1 bypass any 172.24.0.32 255.255.255.224 destination 12.223.2.0 255.255.255.0 sourcegroup skylar

clause 2 permit any 172.24.0.32 255.255.255.224 destination any sourcegroup skylar

apply circuit-(VLAN3)

css-1-gc-N1-LAB#

[seilsz]

Remove the 'sourcegroup skylar' statement from clause 1 of ACL 10.

~Zach

[seilsz]

Can you also post the output of 'sh acl'?

Thanks,

Zach

[scott.dunn]

I have removed the sourcegroup skylar from clause 1. I am still seeing source address translation when going to 12.223.2.8. Here is the output of sh acl:

css-1-gc-N1-LAB# sh acl

Access Control Lists:

Acl: 10

Clause: 1

Action: bypass any

Source: 172.24.0.32/255.255.255.224

Source Port: any

Destination: 12.223.2.0/255.255.255.0

Dest Port: any

Log: disabled

Clause: 2

Action: permit any

Source: 172.24.0.32/255.255.255.224

Source Port: any

Destination: any

Dest Port: any

Source Group: skylar

Log: disabled

css-1-gc-N1-LAB#

[seilsz]

Enable the ACL with the global command:

acl enable

Note the following reference before putting this into production:

http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_tech_note09186a0080093dec.shtml

You'll basically need to make sure that you have an acl permitting traffic applied to all other circuits in the CSS.

~Zach

[seilsz]

I also found the following reference on CCO:

http://www.cisco.com/en/US/products/hw/contnetw/ps789/products_configuration_example09186a008009470e.shtml#steps2

~Zach