cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
3449
Views
10
Helpful
18
Replies
Highlighted
Frequent Contributor

bidirectional vpn access

An ipsec vpn which goes as below in flow,

  Site A  (192.168.112.5) -> Firewall1 -> Firewall2 ->Internet -> Site B (172.16.15.81)

acl on site A firewall 2 where ipsec is defined: access-list 113 extended permit ip host 192.168.112.5 172.16.15.81 255.255.255.224

Site A is using asa & Site B is using  2811.

vpn is running good. from Site B terminal (172.16.15.81) , they can reach Site A terminal(192.168.112.5) on socket 1494. problem is faced when

Site A does the same thing on 1494 to SiteB, it cant connect to that socket on siteB terminal.

Required result should have both Site A & Site B initate & succeed in connecting to each other server on 1494, bidirectionally.

Routing looks fine both ends. access groups are put on firewall1 & 2 , for these needed things.hits can be viewed on these.

Site B server , socket looks good as it is reachable when locally test from site B.

1. capture on firewall1 shows site A sending syn to this site B terminal.

  1:20:52:02.1403996876 112.1Q vlan#112 P0 192.168.112.5.3817 > 172.16.15.81.1494: S 3739309736:3739309736(0) win 65535 <mss 1460,nop,nop,sackOK>

   2: 20:52:03.1403997316 112.1Q vlan#112 P0 192.168.112.5.3817 > 172.16.15.81.1494: S 3739309736:3739309736(0) win 65535 <mss 1460,nop,nop,sackOK>

   3: 20:52:03.1403997816 112.1Q vlan#112 P0 192.168.112.5.3817 > 172.16.15.81.1494: S 3739309736:3739309736(0) win 65535 <mss 1460,nop,nop,sackOK>

2. Capture on firewall 2 when this is tried.

   1: 20:57:17.571381 192.168.112.5.3873 > 172.16.15.81.1494: S 1032152616:1032152616(0) win 65535 <mss 1380,nop,nop,sackOK>

   2: 20:57:18.644238 192.168.112.5.3873 > 172.16.15.81.1494: S 1032152616:1032152616(0) win 65535 <mss 1380,nop,nop,sackOK>

On router at site B, remote person says they have done necessary for this to work. i am awaiting part of the config from them.

Meanwhile, with above detail, please help me if there is something wrong or if some more checks need to be done.do let me know if more output is required.

TIA.

18 REPLIES 18
Highlighted
Enthusiast

On FW2

Check the logs to see if anything is being blocked by the FW itself. Please see also if there is any vpn-filter applied to the tunnel.

On 2811:

You can apply an access-list on the inside interface on the outbound direction to see if you are seeing hitcounts for that particular traffic. Make sure you put a log keyword at the end of the access-list entry and a permit ip any any at the end of the acl. Also a capture on the Site B device can help to see if the syn is reaching there or not.

Highlighted
Frequent Contributor

thank you. on FW-2 no drops are seen.there is no filter used. it says "vpn-filter none" in the  configurations.

router part logs will be done by remote business end.

any other suggestions on this will be appreciated.

TIA

Highlighted

Does running a packet tracer on the FW2 show you anything specific for that traffic?

Also it seems like the remote host is not responding, so best way would be to check with them side by side to see where exactly the packet gets dropped.

Highlighted
Frequent Contributor

yeah, i ran that & got the one below,

packet-tracer input inside tcp 192.168.112.5 1024 172.16.15.81 1494 deta

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xc899ffa8, priority=1, domain=permit, deny=false

        hits=45756275, user_data=0x0, cs_id=0x0, l3_type=0x8

        src mac=0000.0000.0000, mask=0000.0000.0000

        dst mac=0000.0000.0000, mask=0000.0000.0000

Phase: 2

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   172.16.15.80   255.255.255.240 outside

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xc86ce938, priority=500, domain=permit, deny=true

        hits=3271794, user_data=0x8, cs_id=0x0, reverse, flags=0x0, protocol=0

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

i think the deny is shown for inside rule on inside interface. But do we really need a rule for this on inside, will it not take it via crypto acl which states this traffic access.

Thank you & appreciate all help.

Highlighted

Do a "show run access-group" and if you have an access-group applied inbound on the inside interface, you do still need to permit this traffic in the inside ACL even though it will match the crypto ACL later. Putting the traffic inside the VPN does not allow it to bypass the inside ACL.

You might be thinking about a checkbox you saw on ASDM that says something along the lines of allow the VPN to bypass interface acls. This is enabled by default. You might be thinking that should have you covered right? But that checkbox enables the command "sysopt connection permit vpn" and only applies to decrypted traffic (in other words it bypasses access-groups applied to the outside interface where the VPN terminates). It does not cover other interfaces with access-groups that do not terminate the VPN tunnel. See the following command line reference for more info:

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/s8.html#wp1412217

Please remember to rate posts that help you and if the entire issue is resolved, mark the question as answered.

Highlighted
Frequent Contributor

Thanks. i configured the rule on inside interface to permit this traffic. but it doesnt work.Packet trace on FW2 still shows the same output as before.

on FW1 logs, i observed some logs when the attempt was made again to the destination on port 1494.

6|Dec 15 2010 9:59:46|302013: Built inbound TCP connection 12379739848454470738 for VPN-FW1:192.168.112.5/2446 (192.168.112.5/2446) to VPN-FW2:172.16.15.81/1494 (172.16.15.81/1494)

6|Dec 15 2010 9:59:47|302014: Teardown TCP connection 12379739848454470738 for VPN-FW1:192.168.112.5/2446 to VPN-FW2:172.16.15.81/1494 duration 0:00:00 bytes 124 TCP Reset-I

6|Dec 15 2010 9:59:47|302013: Built inbound TCP connection 12379739848454470743 for VPN-FW1:192.168.112.5/2447 (192.168.112.5/2447) to VPN-FW2:172.16.15.81/1494 (172.16.15.81/1494)

6|Dec 15 2010 9:59:47|302014: Teardown TCP connection 12379739848454470743 for VPN-FW1:192.168.112.5/2447 to VPN-FW2:172.16.15.81/1494 duration 0:00:00 bytes 124 TCP Reset-I

6|Dec 15 2010 9:59:48|106028: Deny TCP (Connection marked for Deletion) from 192.168.112.5/2447 to 172.16.15.81/1494 flags SYN  on interface VPN-FW1

what does these logs indicate. top 4 lines i think are quite normal. but the last log for deny tcp is that the culprit here.

a rule do exists on FW1 for this traffic to pass across as intended.

Please help.

TIA

Highlighted
Frequent Contributor

In addition to above , we were provided with some configurations on the remote router.

  interface GigabitEthernet0/0

description vpn connection

switchport access vlan 15

switchport trunk native vlan 15

interface Vlan15

description vpn connection

ip address 172.16.15.1 255.255.248.0 

ip nat inside

ip virtual-reassembly in

acl 144 is the Ipsec rule on router -

access-list 144 permit ip 172.16.15.80 0.0.0.15 192.168.100.0 0.0.0.3

access-list 144 permit ip 172.16.15.80 0.0.0.31 host 192.168.112.5

192.168.100.0 0.0.0.3 is the FW2 interface address.

On our side at FW2 , ipsec rule states-

access-list 113 extended permit ip host 192.168.112.5 172.16.15.80 255.255.255.224

since the interface used is vlan, will it cause problems and should the rule include entire interface subnet even though destination is only 172.16.15.81.

Thanks.

Highlighted

Hi,

The last log entry you have bolded out is not significant. It only means that the SYN has come to the FW1 after the connection has timed out on it.

Could you post the output of the packet-tracer from FW2 again and also a sanitized running-config from it for us to go through?

Cheers,

Prapanch

Highlighted
Frequent Contributor

Thanks here is the new tracer,

packet-tracer input inside tcp 192.168.112.5 1024 172.16.15.81 1494 deta

Phase: 1

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   172.16.15.80   255.255.255.240 outside

Phase: 3

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xc86ce938, priority=500, domain=permit, deny=true

        hits=3378042, user_data=0x8, cs_id=0x0, reverse, flags=0x0, protocol=0

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

I dont mind giving the configs,but would it be ok if i can pass the config as a private message to you. I prefer not to be referenced by the actual ip details since this is my clients device.

Thanks for your help.Pls let me know.

Highlighted

Hi,

I guess for now you can just attach the access-list you have applied on the inside interface. If it has any public IPs, please change it to some random IPs or to other characters.

Cheers,

Prapanch

Highlighted
Frequent Contributor

here is the acl on inside of FW2. this firewall is only used for vpn purpose, no nat happens.

access-list local-access line 1 extended permit ip 192.168.100.0 255.255.255.252 any (hitcnt=0)

access-list local-access line 2 extended permit ip host 192.168.5.0 any (hitcnt=0)

access-list local-access line 3 extended permit icmp any 192.168.190.0 255.255.255.0 (hitcnt=0)

access-list local-access line 4 extended permit tcp host 192.168.112.5 host 172.16.15.81 eq 1494 (hitcnt=0)

Line 4 is used in the site to site vpn that is being said here.

let me know for more information.

Thanks!

Highlighted

Hi,

Looks ok. But interestingly enough we do not see any hit counts agains that line or for that matter against any of the lines. I think we need to take a look at the running config to get a better understanding. Please do change the public IPs and any other sensitive information and paste it here.

Cheers,

Prapanch

Highlighted
Frequent Contributor

Thanks Prapanch.

i have attached the sanitised config. all ip's are fictious.

pls do let me know if anything is not clear.

Appreciate your help!

Highlighted

Hi,

Can't find much from the config. Looks like you have stripped out much of the details out of it and i hope you have not removed the part that mattered!!

Anyway, could you enable logging on the FW and send any logs pertinent to this traffic being dropped by it? That could give us some clue.

Thanks and Regards,

Prapanch

Content for Community-Ad