Solved: Re: Static Natting Web Server

adamgibs7 · ‎03-02-2011

Hello Friends,

I have applied a static Nat for 1 of the server in DMZ interface , I have done proper static Nat and also given for port 80 traffic on outside access list,The strange thing is when i do capture on my outside interface for public IP i recieve the packets for my web server but the connection is not complete.

access-list test permit any host <public IP>

capture test access-list test interface outside.

I m testing by telnet <public IP> 80 from the internet (not by local corporate internet)

I have a AIP SSM module configured in promiscous mode and i have checked in show service policy for any drops but 0 drop count on outside and DMZ interface,

The PUBLIC IP what i m using for web server was on standby ip for outside interface of secondary ASA ,i removed the standby command from primary ASA and put only 1 IP , After removing the IP i did clear arp on ASA and also on DMZ switch.

interface gig0/0

nameif outside

ip add X.X.X.X 255.255.255.224

The servers in DMZ are all in same subnet of DMZ interface so there is no issues of putting route in ASA as they are directly connected to DMZ interface of ASA.

Any hints experts why Web Server is not accessible.

Thanks

PAUL GILBERT ARIAS · ‎03-04-2011

you can use wireshark. On the inside and outside interface you are getting a Reset coming from the server on the inside. I was suggesting the sniffer so that you can get mode details about that reset.

That is why I suspect the issue is on the server.

View solution in original post

PAUL GILBERT ARIAS · ‎03-02-2011

what do you mean about the connection is not complete? What do you see on the capture?

If you want to capture the 3-way hanshake you will need to capture also the return traffic. You will need another ACL allowing that return traffic, for example:

access-list test permit any host

access-list test permit host any

capture test access-list test interface outside

With that you will be able to see the 3-way handshake and the rest of the traffic.

adamgibs7 · ‎03-02-2011

Hello Paul,

These are the capture outputs

PrimaryASA(config)# sh capture test1

3 packets captured

   1: 22:59:40.207890 188.135.54.227.62625 > 85.154.250.91.80: S 2147037942:2147037942(0) win 8192
   2: 22:59:40.787862 188.135.54.227.62625 > 85.154.250.91.80: S 2147037942:2147037942(0) win 8192
   3: 22:59:41.367870 188.135.54.227.62625 > 85.154.250.91.80: S 2147037942:2147037942(0) win 8192
3 packets shown
PrimaryASA(config)# sh capture test2

3 packets captured

   1: 22:59:40.208332 192.168.100.66.80 > 188.135.54.227.62625: R 0:0(0) ack 3662606484 win 0
   2: 22:59:40.788121 192.168.100.66.80 > 188.135.54.227.62625: R 0:0(0) ack 3966402778 win 0
   3: 22:59:41.368129 192.168.100.66.80 > 188.135.54.227.62625: R 0:0(0) ack 3335440784 win 0
3 packets shown

access-list test2 permit tcp host 192.168.100.66 any
PrimaryASA(config)# access-list test2 permit tcp host 192.168.100.66 any
PrimaryASA(config)# capture test2 access-list test2 interface dmz

PrimaryASA(config)# sh access-list test2
access-list test2; 1 elements; name hash: 0x2bb0eb81
access-list test2 line 1 extended permit tcp host 192.168.100.66 any (hitcnt=3) 0xc2c1cc37

Private IP of server is replying see above the 3 hits counts

PrimaryASA(config)# sh access-list test1
access-list test1; 2 elements; name hash: 0x1d34f6f2
access-list test1 line 1 extended permit tcp any host 85.154.250.91 eq www (hitcnt=3) 0x7ae5a997
access-list test1 line 2 extended permit tcp host 85.154.250.91 any eq www (hitcnt=0) 0xa8a33d1d

PrimaryASA(config)# capture test1 access-list test1 interface outside

There is no reply from Natted IP to the internet host hit counts are 0 see above

Thanks

PAUL GILBERT ARIAS · ‎03-02-2011

do you have logs enabled on the ASA? It seems that the ASA is stopping the response or it is being filtered by the AIP.

If you could share the config it would be great.

adamgibs7 · ‎03-02-2011

Hello,

here is the config attached please open with notepad

PAUL GILBERT ARIAS · ‎03-02-2011

One more thing I just noticed about the ACLs you are using for the captures.

The ACLs for the outside capture are not correct since the reply packet has source port 80 and destination port will be random.

Please modfy the ACLS. You can use the following:

access-list test1 line 1 extended permit tcp any host 85.154.250.91 eq www
access-list test1 line 2 extended permit tcp host 85.154.250.91 eq www any

Apply that capture to the outside interface and test again.

Additionally I was not able to see any inspection for HTTP traffic. That might also help you.

adamgibs7 · ‎03-02-2011

Hello,

As per u suggest the access-list i changed i see the replies being sent by the firewall below, but connection is not established.see the attachment.

PrimaryASA(config)# sh capture test1

6 packets captured

   1: 10:14:16.385844 188.135.99.148.54315 > 85.154.250.91.80: S 3224297895:3224297895(0) win 8192
   2: 10:14:16.386347 85.154.250.91.80 > 188.135.99.148.54315: R 1338370117:1338370117(0) ack 3224297896 win 0
   3: 10:14:17.044858 188.135.99.148.54315 > 85.154.250.91.80: S 3224297895:3224297895(0) win 8192
   4: 10:14:17.045178 85.154.250.91.80 > 188.135.99.148.54315: R 1600904395:1600904395(0) ack 3224297896 win 0
   5: 10:14:17.650799 188.135.99.148.54315 > 85.154.250.91.80: S 3224297895:3224297895(0) win 8192
   6: 10:14:17.651104 85.154.250.91.80 > 188.135.99.148.54315: R 366574247:366574247(0) ack 3224297896 win 0
6 packets shown
PrimaryASA(config)# sh access
PrimaryASA(config)# sh access-list test1
access-list test1; 2 elements; name hash: 0x1d34f6f2
access-list test1 line 1 extended permit tcp any host 85.154.250.91 eq www (hitcnt=29) 0x7ae5a997
access-list test1 line 2 extended permit tcp host 85.154.250.91 eq www any (hitcnt=3) 0x9fde51c7

PrimaryASA(config)# sh capture test2

6 packets captured

   1: 10:14:16.386271 192.168.100.66.80 > 188.135.99.148.54315: R 0:0(0) ack 3788472932 win 0
   2: 10:14:17.045133 192.168.100.66.80 > 188.135.99.148.54315: R 0:0(0) ack 781581634 win 0
   3: 10:14:17.651043 192.168.100.66.80 > 188.135.99.148.54315: R 0:0(0) ack 3820632334 win 0
   4: 10:18:09.272523 192.168.100.66.80 > 188.135.99.148.54404: R 0:0(0) ack 2060129704 win 0
   5: 10:18:09.877121 192.168.100.66.80 > 188.135.99.148.54404: R 0:0(0) ack 1993094406 win 0
   6: 10:18:10.492406 192.168.100.66.80 > 188.135.99.148.54404: R 0:0(0) ack 2510069396 win 0
6 packets shown
PrimaryASA(config)# sh access-list test2
access-list test2; 1 elements; name hash: 0x2bb0eb81
access-list test2 line 1 extended permit tcp host 192.168.100.66 any (hitcnt=849) 0xc2c1cc37

PAUL GILBERT ARIAS · ‎03-03-2011

Those captures are showing resets coming from the internal IP, that is the server. Somehow that server is resetting the connection. Were you able to add the inspect http on the policy map?

Can you access that server coming from another host on the same subnet?

adamgibs7 · ‎03-03-2011

hello Paul,

I have added the inspect HTTP in the policy map also.

Can you access that server coming from another host on the same subnet?

Yes

By which logs it is seen tha the server is resetting, i m able to ping the server from internet but i m not able to do telnet on port 80,

Thanks

PAUL GILBERT ARIAS · ‎03-03-2011

I suspect the issue is with the server's http service blocking this connections. Can you set a sniffer on the server capturing this traffic?

adamgibs7 · ‎03-04-2011

Hello Paul,

I should use wireshark for this?? I can get the result for the above, I have 1 doubt if server is droppig the packets then what are the replies seen from Natted IP to public Internet IP on the outside interface capture.

Thanks

PAUL GILBERT ARIAS · ‎03-04-2011

you can use wireshark. On the inside and outside interface you are getting a Reset coming from the server on the inside. I was suggesting the sniffer so that you can get mode details about that reset.

That is why I suspect the issue is on the server.

adamgibs7 · ‎03-06-2011

thanks Paul the issue was with the server.