07-01-2011 10:55 AM - edited 03-11-2019 01:53 PM
Hi,
I have an issue in the Cisco PIx 515e series. The IOS is 6.1(2).
I have set sepecific access-list to allow incoming traffic to inside interface. But still the TCP 3-way handshaking is dropped here.
302001: Built inbound TCP connection 11959955 for faddr 135.86.1.203/2525 gaddr 125.52.207.71/9300 laddr 10.5.2.14/9300
302002: Teardown TCP connection 11959955 faddr 135.86.1.203/2525 gaddr 125.52.207.71/9300 laddr 10.5.2.14/9300 duration 0:00:00 bytes 0 (TCP Reset-I)
nameif ethernet0 outside security0
nameif ethernet2 dmz1 security40
ip address outside 125.52.207.3 255.255.255.0
ip address dmz1 10.5.2.100 255.255.255.0
access-list acl_out permit tcp host 135.86.1.203 host 135.52.207.71 eq 9300
static (dmz1,outside) 135.52.207.72 10.5.2.14 netmask 255.255.255.255 0 0
access-group acl_out in interface outside
route outside 0.0.0.0 0.0.0.0 125.52.207.1 1
Thx.
tabassum
07-01-2011 11:04 AM
Hi,
Can you clarify if the nat'd IP for 10.2.2.14 in DMZ1 is 135.86.1.203? Looking at the public IPs you assigned for outside and default gateway, it should be in the range 125.52.207.x , unless I miss something.
Please confirm this and post the config, if possible.
Thx
MS
07-01-2011 11:13 AM
The 135.86.1.203 IP is an outside client IP address who is trying to connect our server at 125.52.207.71 (which is NATed for the real server 10.5.2.14) on port 9300, sorry for the typo (135.52.207.72).
It would be
static (dmz1,outside) 125.52.207.71 10.5.2.14 netmask 255.255.255.255 0 0
I am getting an error
302001: Built inbound TCP connection 11959955 for faddr 135.86.1.203/2525 gaddr 125.52.207.71/9300 laddr 10.5.2.14/9300
302002: Teardown TCP connection 11959955 faddr 135.86.1.203/2525 gaddr 125.52.207.71/9300 laddr 10.5.2.14/9300 duration 0:00:00 bytes 0 (TCP Reset-I)
The web application is not seeing any traffic hitting and can't find anything in their syslog.
07-01-2011 11:15 AM
Hi Tabassum,
I guess the server ip is 125.52.207.72 and not 135.52.207.72. It looks to me to be a more server issue than a firewall issue.
To verify it you would need to take the captures, something like this:
access-list cap permit ip any host 135.86.1.203 host 125.52.207.72
access-list cap permit ip any host 125.52.207.72 host 135.86.1.203
access-list cap perrmit ip any host 135.86.1.203 host 10.5.2.14
access-list cap perrmit ip any host 10.5.2.14 host 135.86.1.203
and then apply captures:
cap capout access-list cap interface outside
cap capdmz access-list cap interface dmz
Try connecting again, and then collect the captures:
show cap capout
show cap capdmz
It would tell from where the reset is coming.
Hope this helps
Thanks,
Varun
07-01-2011 11:31 AM
varun,
This Cisco pix does not have a "cap" command available.
"cap capout access-list cap interface outside" command is failing.
we are running 6.1(2). Do we have anyother ways to investigate this porblem?
Thx.
tabassum
07-01-2011 11:56 AM
Hi Tabassum,
It becomes difficult troubleshooting on such old versions, may be we can upgrade to version 6.3.5 and then troubleshoot if possible, because looking at the log, it suggest me that the reset was sent by the host on the internal network. so yes, try taking captures on the server machine and check if is sending back SYN ACk packets, you can run wireshark on it.
Thanks,
Varun
07-01-2011 12:06 PM
Thanks Varun.
I will try to capture the packet from the server. It's a Solaris box. I am using snoop to get the details.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide