![]() Packet 2 ( MM Packet 2 in the trace ) is from the responder to agree on one encryption and hash algorithm Packets 3 and 4 arent usually used when troublshooting. ![]() If your encryption fails in Main Mode Packet 1, then you need to check your VPN communities. In IkeView under the IP address of the peer, open the Main Mode Packet 1 - expand : > "P1 Main Mode =>" for outgoing or "P1 Main Mode MM Packet 1 >Security Association >Prop1 PROTO_ISAKMP >Tran1 KEY_IKE You should then be able see the proposed Encryption Algorithm, Key Length, Hash Algorithm, Authentication Method, DH Group, and SA renegotiation params ( life type - usually secs and duration ). Each side generates a symmetric key (based upon the DH key and key material exchanged ). The peers exchange DH Key material (random bits and mathematical data) and methods for PhaseII are agreed for encryption and integrity. Each peer generates a shared secret from its private key and its peers public key, this is the DH key. ![]() Each peer generates a private Diffie-Hellman key from random bits and from that derives a DH public key. Peers Authenticate using Certificates or a pre-shared secret. PHASE1: negotiates encryption methods (DES/3DES/AES etc), the key length, the hash Algorithm (MD5/SHA1) and creates a key to protect the messages of the exchange. Note that another useful tool is " vpn debug on mon " which writes all of the IKE captured data into a file ikemonitor.snoop which you can open with wireshark or ethereal. Check Point have a tool called IKEView.exe which parses the information of ike.elg into a GUI making this easier to view. To enable debugging, you need to login to your firewall and enter the command " vpn debug on vpn debug ikeon " or " vpn debug trunc ". The $FWDIR/log/ike.elg file contains this information ( once debugging is enabled ). By using tunnel-group filters.VPN TROUBLESHOOTING : REFFER: vpn-trouble-shooting.html Basics: IKE negotiation consists of two phases - Phase I (Main mode which is six packets) and Phase II (Quick Mode which is three packets). If using ‘any’ is too broad for your needs you can restrict traffic another way. Optional: Restrict subnets you don’t want in the tunnel To do this we have to use the sla monitor commands. The ASA needs to keep this tunnel up all the time so AWS can initiate traffic back to the ASA. This simply makes it so there is only one SA for this tunnel. This still doesn’t allow users on the AWS side to initiate the tunnel. The any rule is also used so the security association will include the ASA outside interface where the SLA monitor traffic will be sourced from. ![]() If you specify more than one entry for this ACL without using “any” as the source, the VPN will function erratically. If you do not wish to use the “any” source, you must use a single access-list entry for accessing the VPC range. This access list should contain a static route corresponding to your VPC CIDR and allow traffic from any subnet. Here is AWS’s explanation of why this is: Our next steps is to compare our ACL with the remote side’s ACL or VPN traffic definition. The “0.0.0.0/0.0.0.0/0/0” is telling us that the remote side has something else defined in their VPN traffic definition. The interface this is coming in on is our OUTSIDE interface. The peer we are trying to connect to is 77.88.99.100. We can understand this by analyzing the error message “IP = 77.88.99.100, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface OUTSIDE”. Phase 1 was establishing correctly but the interesting traffic wasn’t matching any crypto map I had defined so it wouldn’t create Phase 2. Session Type: LAN-to-LAN, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: crypto map policy not found ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |