cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
531
Views
0
Helpful
3
Replies

NAT and other problems

thibaus
Level 1
Level 1

This has probably been beaten to death here but I am really confused right now as to why this thing doesn't work. Here is the deal. I have service www-1 and www-2 on different machines behind the CSS. For administration and other purposes I have a trunk with VLAN 80 and 81 that route traffic from the public network (10.0.0.0/24) to the private network (192.168.80-81.0/24)behind the CSS. From the same source as the administrators I need to acces the VIPs that for web access. More simply, I need to access both the 192.168.80.x addresses and the 10.0.0.x from the same machine while all transiting through the CSS.

The problem that I have is whenever I access the content from my station (say 10.1.0.x, behind a firewall) the CSS doesn't NAT the source address back to the VIP before forwarding it to my firewall. Case in point here is an example of the flows:

--------------- ----- --------------- ----- --------------- --- ------- ------

Src Address SPort Dst Address DPort NAT Dst Address Prt InPort OutPort

--------------- ----- --------------- ----- --------------- --- ------- ------

192.168.80.11 80 10.1.0.1 4428 10.1.0.1 TCP 1/2-80 1/1

10.1.0.1 4428 10.0.0.1 80 192.168.80.11 TCP 1/1 1/2-80

Where:

10.1.0.1 is my PC

10.0.0.1 is the VIP

192.168.80.11 is the web-server

While my administrative accesses directly to the 192.168.80.11 work perfectly.

I tried every which way to configure source nating (groups or acls) and I seem misunderstand the way they work. Anybody want to give it a shot? here is my config:

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

acl enable

ip route 0.0.0.0 0.0.0.0 10.0.0.254 1

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

interface 1/1

bridge vlan 135

phy 1Gbits-FD-sym

interface 1/2

phy 1Gbits-FD-sym

trunk

vlan 80

vlan 81

vlan 82

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

circuit VLAN80

ip address 192.168.80.252 255.255.255.0

ip virtual-router 1 priority 101 preempt

circuit VLAN135

ip address 10.0.0.252 255.255.255.0

ip virtual-router 2 priority 101 preempt

ip redundant-interface 2 10.0.0.253

ip redundant-vip 2 10.0.0.1

circuit VLAN81

ip address 192.168.81.252 255.255.255.0

ip virtual-router 3 priority 101 preempt

ip redundant-interface 3 192.168.81.254

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

service www-1

ip address 192.168.80.10

keepalive type http

redundant-index 4

port 80

active

service www-2

ip address 192.168.80.11

keepalive type http

redundant-index 5

port 80

active

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

owner owner1

content slvq

add service www-1

add service www-2

vip address 10.0.0.1

url "//www.perdu.com/*"

protocol tcp

port 80

active

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

acl 1

clause 254 permit any any destination any

apply circuit-(VLAN135)

acl 2

clause 254 permit any any destination any

apply circuit-(VLAN81)

acl 3

clause 254 permit any any destination any

apply circuit-(VLAN80)

acl 4

clause 254 permit any any destination any

apply circuit-(VLAN82)

3 Replies 3

Gilles Dufour
Cisco Employee
Cisco Employee

so, your client 10.1.0.x opens a TCP connection to the VIP address 10.0.0.1 and it receives a response directly from the server ip address instead of the vip.

Correct ?

If that's the problem, configuring a group will not help you.

The nating should happen without a group as this is TCP traffic.

The only reason for the CSS not to nat the response is if the response does not make it back to the CSS.

Somehow your server is responding directly to the client without going through the CSS.

You can try to verify this by doing client nat on the css which will force traffic back to the css.

group clientnat

vip addr 10.0.0.1

add destination service www-1

add destination service www-2

active

Regards,

Gilles.

That is exactly what happens. Well the traffic does come back to the CSS, I see it my flows. The only part that I did not mention, and somehow omitted from my copy-paste is that the server's default gateway is 192.168.80.254. My circuit looks like this:

circuit VLAN80

ip address 192.168.80.252 255.255.255.0

ip virtual-router 1 priority 101 preempt

ip redundant-interface 1 192.168.80.254

I do that because I have two CSS that will front this architecture, although the other is not up right now.

Thanks for your help

are your servers directly connected to the CSS ?

Do you have devices connected to the standby CSS ?

We'll need more detail on your setup here.

Gilles.