Do crypto ACLs on ASAs HAVE TO MATCH exactly for the tunnel to come online? I always assumed yes, but is it the case? I am getting mixed answers.
Yes. THEY HAVE TO MATCH EXACTLY.
Exactly as in EXACTLY, same SHA, same DH, same everything. The only difference should be in the direction of the traffic and the ACL used to match it.
This gets messy because by default the ASA has a kitchen sink approach to setting up a VPN and will try everything. You have to get in and carve up precisely what you want to use and be sure that everything else is NOT used.
When your crypto policy has an exact match:
:kidwoohoo:
When there's *just one thing wrong*:
:frustration:
that is what I thought, and thanks for the quick reply. I havent been in ASA in a little over a year. Took a new job as a senior network engineer, and got thrown into a vpn.
Quote from: LynK on November 14, 2017, 08:04:10 AM
Do crypto ACLs on ASAs HAVE TO MATCH exactly for the tunnel to come online? I always assumed yes, but is it the case? I am getting mixed answers.
The ACL is used to define the Proxy ID. If the other end is not an ASA, it should be configured with manual proxy IDs matching exactly the subnets in your ACL, or Phase 2 will not come up.
Not sure if the VTI tunnels are properly implemented already but that would be a more elegant solution. :)
The VPN crypto policy matching is required even when the ASA is not the other end. I had one VPN between an ASA and a Juniper SRG and we had to match ALL. THE. THINGS.
This was me, trying to find how to get the ASA to match things buried in the SRG GUI and vice-versa:
:morty:
ALL. THE. THINGS.
Also don't use the tunnel ACL to do filtering. The interface ACLs are for filtering the VPN ACL is to broadly match interesting traffic. I hate it when one of our partners thinks they are doing security by using very specific match ACLs.
-Otanx
Yes and no:
Each line in an ACL gets it's own ipsec/ikev2 encryption
So your ACEs have to match exactly, but if your entire ACL doesn't match (so 1 ACE doesn't match) all the traffic other than that one ACE will flow nicely I believe.
Probably should test that, but that's how I think it works.
any of you have any site to site VPNs going to china? I cannot figure this out. I got the VPN to work... but then it fails. I am getting these errors:
5 Nov 14 2017 13:08:34 IP = X.X.X.Y, Duplicate first packet detected. Ignoring packet.
5 Nov 14 2017 13:08:49 Local:X.X.X.X:500 Remote:X.X.X.Y:500 Username:Unknown IKEv2 Received request to establish an IPsec tunnel; local traffic selector = Address Range: 10.10.40.106-10.10.40.106 Protocol: 0 Port Range: 0-65535; remote traffic selector = Address Range: 10.10.30.17-10.10.30.17 Protocol: 0 Port Range: 0-65535
3 Nov 15 2017 02:08:37 Tunnel Manager has failed to establish an L2L SA. All configured IKE versions failed to establish the tunnel. Map Tag= CMAP001. Map Sequence Number = 1.
I am getting as far as:
2 IKE Peer: X.X.X.Y
Type : user Role : responder
Rekey : no State : MM_WAIT_MSG3
I have tried everything. This company seems to think it is due to the VPN block in china... but I cannot find anything to back that claim as I am getting messages one way. I am not an ASA beginner, and I have deployed a few of them. I think a TAC call might be in place. I am not certain if that is the issue or not.. but it did come up, and then went offline.
The round trip ICMP takes anywhere from 350-470ms to get to this location in china. Thoughts?
That's a pretty bad time even for getting to China.
They using an ASA with IKEv2 also?
Might help to get their config and make sure it matches.
You can probably do a debugg crypto ikev2 or something like that.
I would probably just call TAC and Tshoot while I am on the call.
China is blocking VPNs. Is this going over an MPLS link or the Internet?
Over the internet. Do you have any documentation that states this? We are running VPN over the internet to china (that is now failing).
Is there any way to run VPN over a different port on the ASA? I am still investigating this.
https://www.eff.org/deeplinks/2017/08/deciphering-chinas-vpn-ban
More if you search on "China VPN ban". I've run into China stuff before, and things work best if they go over an MPLS link and not the WWW.
Does it fail in phase 1 or phase 2?
(https://www.tunnelsup.com/images/IKE_Phase1_MSGs.png)
If you are not sure you are getting a response, run a (filtered) tcpdump on the external interface of your firewall and filter on udp/500 or udp/4500.
Hi Guys,
I am working on the ISP side. The IPSEC is a no-no in China. You should consider MPLS.
Quote from: DesertFox on November 15, 2017, 05:05:14 AM
Hi Guys,
I am working on the ISP side. The IPSEC is a no-no in China. You should consider MPLS.
Building on that: the reason here is that the public internet is heavily censored and filtered in the People's Republic of China, while business networks going over private MPLS links can have their business-only traffic pass through without the level of censorship that goes with public traffic. PRC wants to control civilian usage, not obstruct businesses.
Not going to comment on whether or not PRC is letting business traffic flow so that it can steal intellectual property. Next question, please.
But it will permit encryption of traffic going across private business links. There are also rules on where centralized control devices are allowed to sit. PRC likes them to be sitting in China, whenever possible. And if you think it's impossible, they smile and insist you can try harder. So, that China location may have a WLC even if other sites of its size use Flex Mobility with the 5508 in the Singapore data center...
ADDED: Russia has similar restrictions on civilian VPN usage.
Theres talk of being allowed to officially register VPNs but I ain't got any deets on that.
re: proxy-IDs or the 'interesting traffic ACL', I've seen scenarios where even the order has to match exactly (e.g StrongSwan stack used in a lot of 'nix based appliances). i.e. if you have the same content but the lines are in different order, some stacks will reject this... I'm with Deanwebb, match all the things EXACTLY (heck if you're ASA to ASA then theres no excuse not to, no syntax translation required)
Not helpful probably but policy-based SUCKS - if your ASA version is high enough I believe they finally introduced route based VPNs in latest 9.x
Quote from: deanwebb on November 15, 2017, 08:12:00 AM
Quote from: DesertFox on November 15, 2017, 05:05:14 AM
Hi Guys,
I am working on the ISP side. The IPSEC is a no-no in China. You should consider MPLS.
Building on that: the reason here is that the public internet is heavily censored and filtered in the People's Republic of China, while business networks going over private MPLS links can have their business-only traffic pass through without the level of censorship that goes with public traffic. PRC wants to control civilian usage, not obstruct businesses.
Not going to comment on whether or not PRC is letting business traffic flow so that it can steal intellectual property. Next question, please.
But it will permit encryption of traffic going across private business links. There are also rules on where centralized control devices are allowed to sit. PRC likes them to be sitting in China, whenever possible. And if you think it's impossible, they smile and insist you can try harder. So, that China location may have a WLC even if other sites of its size use Flex Mobility with the 5508 in the Singapore data center...
ADDED: Russia has similar restrictions on civilian VPN usage.
Not sure about encryption over MPLS. Mostly in the mind of the customers and colleagues, MPLS = secure connection, so we are not even trying selling any encryption on top of it.
In Russia restrictions are the devices that could be imported to the country- special license of Cisco routers, etc. Again, we don't have troubles selling MPLS over there.
BTW, I am not sure I didn't find it on this forum indeed, but:
http://www.wired.co.uk/article/china-great-firewall-censorship-fang-binxing
Within China, there can be intense competition within a company to the point where different departments or branches are spying on each other. That leads to encryption within encryption, you co-workers are your biggest insider threat.