cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
615
Views
0
Helpful
9
Replies

L2L VPN Tunnel between a ASA 5505 (9.1) and Cyberoam Firewall appliance

mivbinfotech
Level 1
Level 1

Hi Members

I have 2 appliances as follows:

1. Cisco ASA 5505 Ver 9.1 - fixed Public IP

2. Cyberoam 50ING Firewall Appliance with Dynamic IP which changes at the ISP end

What i am looking to do is establish a site to site vpn.

What i tried is as follows:

- Tried to create a connection profile, by using certificates, but it always sats All IPSEc proposals are unacceptable.

I did play around with crypto maps, etc, with no avail, what i am look at is a step step guid to setup the cisco side of the tunnel either by certificate or by pre shared key.

I can configure the cyberoam side of it, i need to know whether through ADSM can we actually set this up or we have to use CLI, i am looking for a complete step by step procedure any help would be appreciated

Thanks

9 Replies 9

Hi there

I have managed to get the tunnel up and running but i still have a very strange issue

ASA - 

- outside IP 178.1.1.6

- inside subnet 10.1.1.0

Remote End

- outside is dynamic IP

- Local Lan Subnet 10.10.50.0

The issue is i can ping from remot end to server behind asa tunnel is just fine,

but from server behind asa i cant ping remote subnet lan

e.g. ping from 10.10.50.123 is working to 10.1.1.10

ping from 10.1.1.10 not working to 10.10.50.123

below is my running config, i have removed unwanted cert and Ips are all masked any help would be appreciated.  attached is the file

I did  a pactet capture from ASA to the remote subnet is is droppoing the packet on VPN it says

subtype ipsec tunnel flow action drop

Hi, 

One of the limitations of a Dynamic-to-static tunnel is that you can only initiate traffic from the dynamic site , in your case theCyberoam device. 

If the network 10.1.1.0/24 is behind your ASA , the behvihor described might be expected. You can run the command "Show crypto ipsec sa" to verify if the SA has been already created.

-Randy-

Hi there

when i say i am able to pass traffic one way, i meant the tunnel is up successfully and shows active at both ends cyberoam and asa, any other thoughts

issue is not with initiate traffic.

this what the command gives me

interface: outside
Crypto map tag: MAP, seq num: 1, local addr: 178.1.1.6

local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.10.50.0/255.255.255.0/0/0)
current_peer: 83.1.1.1

#pkts encaps: 3, #pkts encrypt: 3, #pkts digest: 3
#pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 3, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0

local crypto endpt.: 178.1.1.6/0, remote crypto endpt.: 83.1.1.1 /0
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: 7802E188
current inbound spi : DEB615CE

inbound esp sas:
spi: 0xDEB615CE (3736475086)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
slot: 0, conn_id: 24576, crypto-map: MAP
sa timing: remaining key lifetime (sec): 17317
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x0000000F
outbound esp sas:
spi: 0x7802E188 (2013454728)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
slot: 0, conn_id: 24576, crypto-map: MAP
sa timing: remaining key lifetime (sec): 17317
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

regards

Hi,

Looks like it could be  with the internal routing or firewall rule, we can determine that using captures. I would place captures on the inside an make sure the returning traffic is hitting the firewall. 

Capture test interface inside match host 10.1.1.10  host10.10.50.123

Capture asp type asp-drop all 

The first capture will tell us if the ping from 10.1.1.10 is hitting the firewall , the second capture will indicate if the firewall is dropping this traffic. 

Show capture test

Show capture asp | incl 10.1.1.10 

Hope it helps

-Randy-

Hi there the capture syntax provided was wrong the "ip" before host was missing

the result of first capture is 

12 packets captured

1: 03:29:23.860917 802.1Q vlan#1 P0 10.1.1.10 > 10.10.50.13: icmp: echo request
2: 03:29:28.638104 802.1Q vlan#1 P0 10.1.1.10 > 10.10.50.13: icmp: echo request
3: 03:29:33.630155 802.1Q vlan#1 P0 10.1.1.10 > 10.10.50.13: icmp: echo request
4: 03:29:38.637860 802.1Q vlan#1 P0 10.1..10 > 10.10.50.13: icmp: echo request
5: 03:29:43.629880 802.1Q vlan#1 P0 10.1.1.10 > 10.10.50.13: icmp: echo request
6: 03:29:48.637555 802.1Q vlan#1 P0 10.1.1.10 > 10.10.50.13: icmp: echo request
7: 03:29:53.629529 802.1Q vlan#1 P0 10.1.1.10 > 10.10.50.13: icmp: echo request
8: 03:29:58.637158 802.1Q vlan#1 P0 10.1.1.10 > 10.10.50.13: icmp: echo request
9: 03:30:03.629148 802.1Q vlan#1 P0 10.1.1.10 > 10.10.50.13: icmp: echo request
10: 03:30:08.636853 802.1Q vlan#1 P0 10.1.1.10 > 10.10.50.13: icmp: echo request
11: 03:30:13.628797 802.1Q vlan#1 P0 10.1.1.10 > 10.10.50.13: icmp: echo request
12: 03:30:18.636517 802.1Q vlan#1 P0 10.1.1.10 > 10.10.50.13: icmp: echo request

the second capture does not show anything at all its blank

As we see the traffic initiated from the ASA is not getting replies from the 10.10.50.13, this indicate the problem is most likely at the other side of the tunnel. Not on the ASA. 

-Randy-

Hi there

this is incorrect, we ran a similar packet capture on teh remote end and see no traffic is being sent by asa to the remote end.

interesting, if there is an issue at the remote end, how is 1 way traffic which is initiated from remote end working.

I am now wondering whether doing a firmware upgrade is a possible work around, as i fail to see why one way traffic is not working, 

regards