CSS onearm through ASA - NAT help please

joe.arnstein · ‎01-16-2008

Hi,

I am trying to use our CSS like a reverse proxy to get web traffic back into our core network from the outside world, just for this one server. In a one-armed fashion, the CSS passes the packet through the firewall to be routed inside, but it drops with the following error:

Deny TCP reverse path check from 65.65.65.166 to 10.10.10.35 on interface dmz1

The problem is, the CSS is preserving the client's IP address causing an anti-spoofing alert on the firewall--I would like to hide the source behind an IP on the CSS instead.

Here's the config--sorry for the added complexity, but I am piggy-backing off our main website's SSL config to avoid buying a new cert, so I'm including the frontend and backend rules for that as well:

The goal: send https://www.localgov.gov/special from the CSS in our DMZ to a server inside our LAN.

DNS for http://www.localgov.gov = 111.11.11.135

CSS Frontend network range 111.11.11.128/25

CSS Backend 172.16.1.x/24

LAN Internal 10.10.10.0/24

CSS rules are set up like this (forgive me if I'm putting in too much info...):

ssl-proxy-list localgov-ssl

ssl-server 1

ssl-server 1 vip address 111.11.11.135

ssl-server 1 rsakey myrsakey1

ssl-server 1 rsacert localgov2007

ssl-server 1 cipher rsa-with-rc4-128-md5 172.16.1.29 80 weight 10

ssl-server 1 cipher rsa-with-rc4-128-sha 172.16.1.29 80 weight 9

ssl-server 1 cipher rsa-with-3des-ede-cbc-sha 172.16.1.29 80 weight 8

ssl-server 1 urlrewrite 22 http://www.localgov.gov

content LocalGov-http

vip address 111.11.11.135

add service server1

add service server2

add service server3

advanced-balance arrowpoint-cookie

protocol tcp

port 80

url "/*"

balance aca

sticky-inact-timeout 60

sticky-mask 255.255.255.0

active

content localgov-frontend-ssl

vip address 111.11.11.135

add service ssl-module

protocol tcp

port 443

active

content localgov-backend-ssl

add service server1_backend_ssl

add service server2_backend_ssl

add service server3_backend_ssl

vip address 172.16.1.29

advanced-balance arrowpoint-cookie

balance aca

protocol tcp

port 80

active

content Special-https

vip address 172.16.1.29

add service special-server-https

protocol tcp

port 80

url "//www.localgov.gov/special*"

active

service special-server-https

ip address 10.10.10.35

protocol tcp

port 80

keepalive type http

keepalive frequency 60

active

service ssl-module

type ssl-accel

slot 2

keepalive type none

add ssl-proxy-list localgov-ssl

active

group fromLocalGov

vip address 111.11.11.135

add service server1

add service server2

add service server3

active

***Usually when I set up one-armed configs we need destination service in the source group. At this time I've got nothing for the special server in there.

I need to set this up so that traffic destined into the server appear to come from the CSS (or some other DMZ address) so that the firewall doesn't drop the traffic.

Thanks for your help!

Joe

Gilles Dufour · ‎01-17-2008

Joe,

you'll need to use a group for that.

But since your server are already listed in a group, you can't add them statically to another one.

The solution is to use an acl to dynamically link the traffic to a group when needed.

To do that, create a group and configure a vip for the group (whatever your firewall will accept).

Do not add any services and just activate the group.

Then configure an acl to match the traffic that need to be nated.

ie:

acl 1

clause 10 permit any destination content sourcegroup

ACL are applied inbound.

So if the destination is a vip, you need to use the example above. If the destination is not a vip, you need to replace the "content " with the destination ip address.

Gilles.

joe.arnstein · ‎01-23-2008

Hi Gilles,

Thanks for taking the time to respond! I just got back from my vacation and wanted to ask a question about your recommendation before I add it to our CSS.

If I understand you correctly, the ACL example says if anyone hits content rule "Special-https", they should take the IP in the sourcegroup Special (see below). Right?

We do not have any ACLs on this CSS yet, but from what I understand if you add an ACL to one interface you have to add one to all of them. Is that right? If so, here's what I plan to add:

"

group Special

111.11.11.136

active

acl 1

clause 1 permit any any destination content SPECIAL/Special-https sourcegroup Special

clause 2 permit any any destination any

apply circuit-(VLAN111)

acl 2

clause 1 permit any any destination any

apply circuit-(VLAN172)

acl enable

"

Does that look about right?

Thanks again,

Joe

joe.arnstein · ‎01-23-2008

Here is a follow-up: Does not work yet but I'm not giving up hope! I added a new VIP to the CSS (111.11.11.139) and put that into the source group Special:

group Special

111.11.11.139

active

To confirm again what I THINK will happen with this ACL NAT rule:

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

client --> CSS

65.65.65.22 111.11.11.135

CSS (VIP) --> Special backend server

111.11.11.139 10.10.10.35

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

I added the first and second attempts at "clause 1" to the inside interface(VLAN 172), and when that didn't work I added it to the outside one (VLAN 111).

internal VLAN:

acl 1

***first try***

clause 1 permit any any destination content SPECIAL/Special-https sourcegroup Special

***second try***

clause 1 permit any any destination 10.10.10.35 255.255.255.255 sourcegroup Special

clause 2 permit any any destination any

apply circuit-(VLAN172)

(External VLAN)

acl 2

***third try***

clause 1 permit any any destination content SPECIAL/Special-https sourcegroup Special

***fourth try***

clause 1 permit any any destination 10.10.10.35 255.255.255.255 sourcegroup Special

clause 2 permit any any destination any

apply circuit-(VLAN111)

What's still happening is:

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

client --> CSS

65.65.65.22 111.11.11.135

CSS --> Special backend server

65.65.65.22 10.10.10.35

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

There are no hits to ACL clause 1 on either interface, but I do see the owner/content rule incrementing with each hit from outside.

Thank you again for taking the time to look at this! I appreciate your suggestions.

Joe

joe.arnstein · ‎01-24-2008

FIXED!

It did indeed need a group with destination service as follows:

group Special

vip 111.11.11.139

add destination service special-server-https

active

Destination service in a group NATs traffic destined to the IP in the respective service to the VIP of that group.

Simple one...thanks to Cisco TAC for the sanity check, and to gdufour for taking the time to write a suggestion! You lead me down the right track by creating a new VIP to bind to the group.

Joe