%PIX-2-106001: Inbound TCP connection denied from inside

Unanswered Question
May 31st, 2007

Hi

I am getting the following errors when trying to ssh between 2 servers over the VPN tunnel. I see it is going out of my acl_inside access-list but I do not see it reaching the VPN acess list. There is no natting between the 2 ips.

Thanks,

# no natting for 10.13.36.0 subnet to 10.2.0.0 subnet

access-list nonat extended permit ip 10.13.36.0 255.255.254.0 10.2.0.0 255.255.192.0

# acl_in access list

access-list acl_in line 4 extended permit tcp host 10.13.37.245 host 10.2.12.202 (hitcnt=28)

access-list acl_in line 31 extended permit ip 10.13.36.0 255.255.254.0 10.2.0.0 255.255.192.0 (hitcnt=462)

# VPN access list

access-list XO_access_in line 5 extended permit tcp host 10.2.12.202 eq ssh host 10.13.37.245 (hitcnt=0)

%PIX-2-106001: Inbound TCP connection denied from 10.13.37.245/58736 to 10.2.12.202/22 flags SYN on interface inside

# show version

Cisco PIX Security Appliance Software Version 7.0(4)

Device Manager Version 5.0(4)

Compiled on Thu 13-Oct-05 21:43 by builders

System image file is "flash:/pix704.bin"

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
ggilbert Thu, 05/31/2007 - 12:24

Instead of this access-list, can you replicate your nonat acl.

access-list XO_access_in line 5 extended permit tcp host 10.2.12.202 eq ssh host 10.13.37.245

Like this:

access-list XO_access_in extended permit ip 10.13.36.0 255.255.254.0 10.2.0.0 255.255.192.0

(Make sure it matches on the remote side as well - Mirror image)

Try that out.

After that, send me the output of

"sh cry ipsec sa"

Thanks

Gilbert

Mrkaprino Thu, 05/31/2007 - 14:05

attached is teh runnig config

access-list nonat extended permit ip 10.13.36.0 255.255.254.0 10.2.0.0 255.255.192.0

here is out put from show crypto ipsec sa.

PIX-FW# show crypto ipsec sa

interface: XO

Crypto map tag: XO_map, seq num: 40, local addr: XXX.XXX.XXX.XXX

access-list XO_cryptomap_40_1 permit ip 10.13.36.0 255.255.254.0 10.2.0.0

255.255.192.0

local ident (addr/mask/prot/port): (10.13.36.0/255.255.254.0/0/0)

remote ident (addr/mask/prot/port): (10.2.0.0/255.255.192.0/0/0)

current_peer: YYY.YYY.YYY.YYY

#pkts encaps: 711296, #pkts encrypt: 711296, #pkts digest: 711296

#pkts decaps: 567206, #pkts decrypt: 567205, #pkts verify: 567205

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 711296, #pkts comp failed: 0, #pkts decomp failed: 0

#send errors: 0, #recv errors: 1

local crypto endpt.: XXX.XXX.XXX.XXX, remote crypto endpt.: YYY.YYY.YYY.YYY

path mtu 1500, ipsec overhead 60, media mtu 1500

current outbound spi: 221A150D

inbound esp sas:

spi: 0x19BCB304 (431796996)

transform: esp-3des esp-md5-hmac

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 14, crypto-map: XO_map

sa timing: remaining key lifetime (kB/sec): (3824986/2691)

IV size: 8 bytes

replay detection support: Y

outbound esp sas:

spi: 0x221A150D (572134669)

transform: esp-3des esp-md5-hmac

in use settings ={L2L, Tunnel, }

slot: 0, conn_id: 14, crypto-map: XO_map

sa timing: remaining key lifetime (kB/sec): (3824994/2691)

IV size: 8 bytes

replay detection support: Y

Attachment: 
ggilbert Fri, 06/01/2007 - 09:38

You have a route statement "route XO 10.2.0.0 255.255.192.0 YYY.YYY.YYY.YYY 1" which isnt needed.

There should be a default route statement "route XO 0.0.0.0 0.0.0.0 nexthopip" - that should take care of the routing part.

Also, can you remove the filter value to none under the group policy.

Right now, it is "vpn-filter value UK-ACL"

make it vpn-filter value "none"

Let me know how it goes.

Sorry for the delay in answering.

Cheers

Gilbert

Mrkaprino Sat, 06/02/2007 - 09:04

Gilbert,

I forgot mention to you we have setup the VPN tunnel over XO interface(backup T1to internet), instead of the default outside interface. So we need to route UK's network (10.2.0.0) over XO interface, instead of default outside. We were able to connect to UK network a while back, but I am not sure what has chnaged to cause all the connection problems.

It is hitting th correct ACL on the inside interface, but I do not see the hit counters on the ACLs on the UK VPN tunnel afterwards. Should it then hit the ACL on the XO interface , then to the ACL on the UK VPN tunnel??

Thanks a million,

Kaprino

ggilbert Tue, 06/05/2007 - 05:02

Kaprino,

Did you make the filter changes as per my last post. Did you clear the tunnels after that, "cle cry isa sa" & " cle cry ipsec sa".

Is still not working?

Cheers,

Gilbert

Mrkaprino Tue, 06/05/2007 - 17:03

Gilbert

For the time being, we have move the server to the DMZ and allow access over the internet.

I will try to clear both crypto isa sa and ipsec sa, tomorrow. This will bring down the VPN tunnel, correct?

THanks,

Kaprino

ggilbert Wed, 06/06/2007 - 03:06

Kaprino,

You are correct. It will bring down the tunnel.

After you bring up the tunnel, can you send me the output of "sh vpn-sessiondb l2l"

Thanks

Gilbert

msharifi Sun, 06/03/2007 - 19:17

Make sure you have an acl to support bidirectional traffic between both hosts.

thult Tue, 06/05/2007 - 01:38

The access-list XO_access_in are not used in this scenario, only the acl_in and UK-ACL filter(and of course the crypto and nonat lists)

It looks like a stateful error (the ACL filters are stateless), where the return traffic is not configured. After checking the configuration it does seem as you have covered the return traffic.

My tip is that if you made a change to the UK_ACL access-list you have to bring down the VPN tunnel manually before the changes are activated.

Mrkaprino Tue, 06/05/2007 - 17:00

Thanks all for the suggestions, So I was correct that I have all the necessary ACLs both inside and UK_ACL. From all the previous VPN changes,I never had to bring down the VPN tunnel, but it would be a good start.

Thanks,

Kaprino

Actions

This Discussion