01-16-2008 01:17 PM
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
01-17-2008 12:40 AM
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
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
Gilles.
01-23-2008 02:19 PM
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
01-23-2008 03:53 PM
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
01-24-2008 01:18 PM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: