IPSec GRE tunnel without a public IP address

[fimonteiro]

Hello,

Can an IPSec GRE tunnel be created without the public IP address on our router interface? So, one of the routers has a public IP address and the other router is behind the ISP router on a private subnet.

The ISP on one of our sites is telling us that they cannot configure their ADSL router in bridge mode. So the public IP address is not configured on our router dialer interface. Instead the ISP edge router has the public IP and they are suggesting to configure a one to one static NAT.

Will this work?

Is there any security risk?

Appreciate any help suggestions and solution for this scenario.

[Deepak Kumar]

Hi,

Yes, It will work and I am not looking any security issue if you will configure well lengthy PSK.  

But, here keep in mind that Your Router which is having Private IP on Interface will connection initiator of the secure tunnel. 

I hope this link can guide you better: http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/936-cisco-router-vpn-dynamic-endpoint.html

Regards,

Deepak Kumar

[Richard Burts]

I agree with Deepak that this will work. And I speak from experience. I have configured for several customers GRE with IPSec where one of the routers had a private IP address on its outside interface. As long as there is a one to one static address translation on the ISP router that will forward all the traffic for that IP to your router then the site to site vpn should work successfully.

I do not agree with Deepak that there is a restriction that the router with the private IP must initiate the vpn. As long as there is static address translation either peer should be able to initiate the vpn. 

HTH

Rick

[Deepak Kumar]

Hi @Richard Burts 

I am aware of the statement which you had quote. But I commented those lines based on

The ISP on one of our sites is telling us that they cannot configure their ADSL router in bridge mode. So the public IP address is not configured on our router dialer interface.

So Basic assume that there is no static IP address. He may configure with DYDNS.

Regards,

Deepak Kumar

[Richard Burts]

@Deepak Kumar You interpret the original post in one way, assuming that if there is not a static public that the address is likely to be dynamic in nature. I agree that if the outside interface IP is dynamic then there is a restriction that the dynamic peer must be the one to initiate the vpn. But I interpret the original post differently than you did-especially the part that says:

they are suggesting to configure a one to one static NAT.

That is why I included in my response

As long as there is static address translation either peer should be able to initiate the vpn. 

So you interpret one way and I interpret a different way. Perhaps the original poster will clarify which way it is.

HTH

Rick

[fimonteiro]

Thank you very much for your inputs.

Theoretically I thought it could work but I could not find any post that confirmed that so I was in doubt. And I wanted to be sure I was not creating any security risk with this setup.

And yes the ISP provides a static public IP address. At least that they were able to provide ;)

I will ask the ISP to configure the one to one static NAT on their router and configure the tunnels.

I will let you know is I was successful to establish this tunnels.

Once again thank you very much for your help.

[fimonteiro]

BTW do you think it preferable for security reasons to ask the ISP to configure a 31 bit subnet on their router so that my router gets a private IP with no other hosts that could be listening to the broadcast on that subnet?

Does a 31 bit subnet works?

[Richard Burts]

In a logical sense a /31 should work. My opinion is that it would not particularly increase the security of your connection. 

HTH

Rick

[fimonteiro]

I thought that not having more devices listening on that subnet broadcast, and since that circuit will also be use for normal internet access along with the IPSec/GRE tunnel, would increase a little bit the security. I mean I don't what else could be connected on that ISP router built in switch that could for example capture broadcast traffic. Maybe I'm thinking wrong.

Thanks! :)

[Richard Burts]

If you are concerned about the security implications of the Internet connection you may want to consider that it is as likely that someone could put a device connected to that Ethernet that is passively listening and capturing your traffic as is likely that someone would put a device on the Ethernet giving it an address in the subnet and listening to your broadcast traffic. Also think about what could they learn that was significant if they were listening to your broadcast traffic. What do you send out the Internet interface as broadcast, other than arp?

HTH

Rick

[Deepak Kumar]

Hi,

As @Richard Burts asked what will you send on the internet as broadcast. I will not worry except the ARP spoofing. But It is a risk only.

Regards,

Deepak Kumar

[fimonteiro]

ISAKMP is stuck with the error MM_KEY_EXCH.

Look it up and it means either the configured pre-shared key is not correct or the peer IP addresses are different. 

I know the pre-shared key is correct so my dough goes to the peer IP address since we are behind a static NAT.

How exactly should I configure the crypto map and crypto isakmp key in this case?

192.168.1.2 (my router1 int) <---> 192.168.1.1 (ISP private subnet) 111.111.111.111 (ISP public static IP) <---> 222.222.222.222 (my other router2 public static IP)

Router 1 config

crypto isakmp key PASSWORD address 222.222.222.222

crypto map site_crypto 22222 ipsec-isakmp
description GRE to ROUTER2
set peer 222.222.222.222
set transform-set trans_aes256_sha
set pfs group5
qos pre-classify

Router 2 config

crypto isakmp key PASSWORD address 111.111.111.111

crypto map site_crypto 11111 ipsec-isakmp
description GRE to ROUTER2
set peer 111.111.111.111
set transform-set trans_aes256_sha
set pfs group5
qos pre-classify

[Richard Burts]

The partial config that you posted seems appropriate. I would suggest that you run debug for isakmp on both routers and post the debug output. I will be especially interested in the debug output from the router where there is static nat.

And if the error seems to be pointing at a mismatch in passwords it would not be a bad idea to configure a new password on both routers, just in case there was an error on one side.

HTH

Rick

[fimonteiro]

Debug for Router 1 (the one behind the static NAT)

416410: Mar 28 14:23:07.138 UTC: ISAKMP:(0):purging node -1742861624
416411: Mar 28 14:23:07.138 UTC: ISAKMP:(0):purging node -1281255356
416412: Mar 28 14:23:07.138 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
416413: Mar 28 14:23:07.138 UTC: ISAKMP (0): incrementing error counter on sa, attempt 2 of 5: retransmit phase 1
416414: Mar 28 14:23:07.138 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
416415: Mar 28 14:23:07.138 UTC: ISAKMP:(0): sending packet to 222.222.222.222 my_port 500 peer_port 500 (I) MM_NO_STATE
416416: Mar 28 14:23:07.138 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.

416418: Mar 28 14:23:17.138 UTC: ISAKMP:(0):purging SA., sa=2CE82EF8, delme=2CE82EF8
416419: Mar 28 14:23:17.138 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
416420: Mar 28 14:23:17.138 UTC: ISAKMP (0): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1
416421: Mar 28 14:23:17.138 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
416422: Mar 28 14:23:17.138 UTC: ISAKMP:(0): sending packet to 222.222.222.222 my_port 500 peer_port 500 (I) MM_NO_STATE
416423: Mar 28 14:23:17.138 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.
416424: Mar 28 14:23:17.230 UTC: ISAKMP: set new node 0 to QM_IDLE

416425: Mar 28 14:23:17.230 UTC: ISAKMP:(0):SA is still budding. Attached new ipsec request to it. (local 192.168.1.2, remote 222.222.222.222)
416426: Mar 28 14:23:17.230 UTC: ISAKMP: Error while processing SA request: Failed to initialize SA
416427: Mar 28 14:23:17.230 UTC: ISAKMP: Error while processing KMI message 0, error 2.

416428: Mar 28 14:23:27.138 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
416429: Mar 28 14:23:27.138 UTC: ISAKMP (0): incrementing error counter on sa, attempt 4 of 5: retransmit phase 1
416430: Mar 28 14:23:27.138 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
416431: Mar 28 14:23:27.138 UTC: ISAKMP:(0): sending packet to 222.222.222.222 my_port 500 peer_port 500 (I) MM_NO_STATE
416432: Mar 28 14:23:27.138 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.

416434: Mar 28 14:23:35.478 UTC: ISAKMP:(0):purging node -557741524
416435: Mar 28 14:23:37.138 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
416436: Mar 28 14:23:37.138 UTC: ISAKMP (0): incrementing error counter on sa, attempt 5 of 5: retransmit phase 1
416437: Mar 28 14:23:37.138 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
416438: Mar 28 14:23:37.138 UTC: ISAKMP:(0): sending packet to 222.222.222.222 my_port 500 peer_port 500 (I) MM_NO_STATE
416439: Mar 28 14:23:37.138 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.

416441: Mar 28 14:23:45.478 UTC: ISAKMP:(0):purging SA., sa=41066454, delme=41066454

416443: Mar 28 14:23:47.138 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
416444: Mar 28 14:23:47.138 UTC: ISAKMP:(0):peer does not do paranoid keepalives.

416445: Mar 28 14:23:47.138 UTC: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer 222.222.222.222)
416446: Mar 28 14:23:47.138 UTC: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer 222.222.222.222)
416447: Mar 28 14:23:47.138 UTC: ISAKMP: Unlocking peer struct 0x2D13A9A8 for isadb_mark_sa_deleted(), count 0
416448: Mar 28 14:23:47.138 UTC: ISAKMP: Deleting peer node by peer_reap for 222.222.222.222: 2D13A9A8
416449: Mar 28 14:23:47.138 UTC: ISAKMP:(0):deleting node 1851363487 error FALSE reason "IKE deleted"
416450: Mar 28 14:23:47.138 UTC: ISAKMP:(0):deleting node -1692435693 error FALSE reason "IKE deleted"
416451: Mar 28 14:23:47.138 UTC: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
416452: Mar 28 14:23:47.138 UTC: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_DEST_SA

416453: Mar 28 14:23:47.230 UTC: ISAKMP:(0): SA request profile is (NULL)
416454: Mar 28 14:23:47.230 UTC: ISAKMP: Created a peer struct for 222.222.222.222, peer port 500
416455: Mar 28 14:23:47.230 UTC: ISAKMP: New peer created peer = 0x2D13A9A8 peer_handle = 0x80000AC9
416456: Mar 28 14:23:47.230 UTC: ISAKMP: Locking peer struct 0x2D13A9A8, refcount 1 for isakmp_initiator
416457: Mar 28 14:23:47.230 UTC: ISAKMP: local port 500, remote port 500
416458: Mar 28 14:23:47.230 UTC: ISAKMP: set new node 0 to QM_IDLE
416459: Mar 28 14:23:47.230 UTC: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = C14BDD68
416460: Mar 28 14:23:47.230 UTC: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
416461: Mar 28 14:23:47.230 UTC: ISAKMP:(0):found peer pre-shared key matching 222.222.222.222
416462: Mar 28 14:23:47.230 UTC: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
416463: Mar 28 14:23:47.230 UTC: ISAKMP:(0): constructed NAT-T vendor-07 ID
416464: Mar 28 14:23:47.230 UTC: ISAKMP:(0): constructed NAT-T vendor-03 ID
416465: Mar 28 14:23:47.230 UTC: ISAKMP:(0): constructed NAT-T vendor-02 ID
416466: Mar 28 14:23:47.230 UTC: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
416467: Mar 28 14:23:47.230 UTC: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1

416468: Mar 28 14:23:47.230 UTC: ISAKMP:(0): beginning Main Mode exchange
416469: Mar 28 14:23:47.230 UTC: ISAKMP:(0): sending packet to 222.222.222.222 my_port 500 peer_port 500 (I) MM_NO_STATE
416470: Mar 28 14:23:47.230 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.
416471: Mar 28 14:23:47.334 UTC: ISAKMP (0): received packet from 222.222.222.222 dport 500 sport 500 Global (I) MM_NO_STATE
416472: Mar 28 14:23:47.334 UTC: ISAKMP:(0):Notify has no hash. Rejected.
416473: Mar 28 14:23:47.334 UTC: ISAKMP (0): Unknown Input IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY: state = IKE_I_MM1
416474: Mar 28 14:23:47.334 UTC: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
416475: Mar 28 14:23:47.334 UTC: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_I_MM1

416476: Mar 28 14:23:47.334 UTC: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Informational mode failed with peer at 222.222.222.222

416478: Mar 28 14:23:57.230 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
416479: Mar 28 14:23:57.230 UTC: ISAKMP (0): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1
416480: Mar 28 14:23:57.230 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
416481: Mar 28 14:23:57.230 UTC: ISAKMP:(0): sending packet to 222.222.222.222 my_port 500 peer_port 500 (I) MM_NO_STATE
416482: Mar 28 14:23:57.230 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.

416484: Mar 28 14:24:07.230 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
416485: Mar 28 14:24:07.230 UTC: ISAKMP (0): incrementing error counter on sa, attempt 2 of 5: retransmit phase 1
416486: Mar 28 14:24:07.230 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
416487: Mar 28 14:24:07.230 UTC: ISAKMP:(0): sending packet to 222.222.222.222 my_port 500 peer_port 500 (I) MM_NO_STATE
416488: Mar 28 14:24:07.230 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.

416489: Mar 28 14:24:17.230 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
416490: Mar 28 14:24:17.230 UTC: ISAKMP (0): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1
416491: Mar 28 14:24:17.230 UTC: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
416492: Mar 28 14:24:17.230 UTC: ISAKMP:(0): sending packet to 222.222.222.222 my_port 500 peer_port 500 (I) MM_NO_STATE
416493: Mar 28 14:24:17.230 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.
416494: Mar 28 14:24:17.318 UTC: ISAKMP: set new node 0 to QM_IDLE
416495: Mar 28 14:24:17.318 UTC: ISAKMP:(0):SA is still budding. Attached new ipsec request to it. (local 192.168.1.2, remote 222.222.222.222)
416496: Mar 28 14:24:17.318 UTC: ISAKMP: Error while processing SA request: Failed to initialize SA
416497: Mar 28 14:24:17.318 UTC: ISAKMP: Error while processing KMI message 0, error 2.

[Richard Burts]

Thanks for the debug output. One thing I was looking for was to verify that the router was receiving the ISAKMP messages from the peer (verify that the address translation was working). And I do see messages received. So it seems the address translation is ok.

I do see this message in the output

:found peer pre-shared key matching 222.222.222.222

while it may not be conclusive I believe it does indicate that the shared key is not the problem.

There is some ISAKMP packets received. But I see a lot of this router sending a packet, and retransmitting, and retransmitting and seems not to be receiving responses. Do you have debug output from the other router?

HTH

Rick