Screen OS

Hi,

Firstly, I have already seen the KB3256 that speaks about this configuration but i still have questions.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB3256&act=RATE&newguid=024802203f346e33013c3...

So here is the setup im attempting to build:

(Client Network ==> Cisco Router ==> Cisco ASA )====== Internet Cloud <=======> (Juniper ISG 1000 ==> Server Network)

The cisco router does the GRE tunnel, the Cisco ASA does the IPSEC tunnel. On the other end of the Internet cloud, the Juniper ISG does both the IPSEC + GRE.

I do not have experience with Juniper ISG devices and am just assuming things based on the general Network experience.

In the KB above, the GRE tunnel destination is a directly connected interface to the Router and hence a Separate route was not required to be pointed towards the tunnel destination through the IPSEC tunnel.

But in most normal cases, the GRE tunnel destination is elsewhere and a Separate route is required to be pointed towards the IPSEC part of the configuration to get the GRe tunnel working.

However, in the Solution in the KB, the IPSEC tunnel is being bound to Tunnel1 which is actually the GRE Tunnel Interface.

Now, i don't seem to understand how one would route the GRE tunnel destination towards the IPSEC tunnel when the GRE Tunnel Interface and the IPSEC tunnel interface are the one and the same?


Could someone please clarify. Let me know if more information is required.

thanks,
Victor

Hi,

I have never tried this but can you check the following.

In the tunnel interface configuration, under GRE, for the dst-ip keep the ip address of the cisco router.

From the kb, instead of using GRE destination as 1.1.1.2, you can use the router ip in there.

Regards.

Hardeep

Hello,

Thanku for you response.

Yeah thats ok. I am using the appropriate Ip addressing for the tunnel destination, But how does the Router know that to reach the tunnel destination, traffic has to go through the IPSEC tunnel when the IPSEC tunnel is bound to the same Tunnel interface as the GRE tunnel?

Hi,

The FW will first decapsulate and decrypt the ESP payload and then if the destination of the packet is the GRE enabled tunnel interface, the GRE decapsulation will kick in.
From the KB, the tunnl IP is 10.1.1.1.
Cisco ASA will need to have the ACLs setup so that it can send GRE- traffic for destination 10.1.1.1 towards the IPsec tunnel and once it reaches the Juniper end it should be able to handle it accordingly.

Not sure if this helps but just wanted to share my understanding. 🙂

Regards.
Hardeep

Thankyou for you inputs Hardeep. I have the Cisco side of the config done up correctly already.

Im confused about how the Juniper ISG will handle the IPSEC + GRE given that the KB binds the IPSEC to the GRE Tunnel interface itself.

Lets see if anyone else can help.

From the KB, the following route is pointing to the tunnel interface.

set route  1.1.3.0/24 interface tunnel.1

Once traffic hits the tunnel interface the GRE properties of tunnel will place the packet in GRE tunnel and then the IPsec properties are applied to it.
If you have any specific doubts on a specific part of  the firewall logic, I can try to get answers to it, else we can wait to see if someone else has a better explanation.

Regards.
Hardeep

Right, 

The Packet is first being GRE excapsulated per logic correctly. But how does the GRE interface know which direction to go to reach to the GRE tunnel destination?

And i found this note on KB6126

IMPORTANT NOTE: 

When creating the GRE tunnel over an IPSEC tunnel, the GRE configuration needs to be added first before the IPSEC configuration.  This configuration order is important because if the firewall is rebooted, it loads the GRE over IPSEC configuration in that order. However, if GRE is not configured first, the firewall will load the IPSEC first and then try to set the IPSEC over GRE.  This will cause the communication to fail with the remote device.

The Packet is first being GRE encapsulated per logic correctly. But how does the GRE interface know which direction to go to reach to the GRE tunnel destination?

On the GRE settings of the tunnel interface you define the detination IP address of remote end, this will act as the decisive factor to give direction to GRE tunnel.

Packet hits firewall ----> Matches tunnel interface ----> Tunnel interface has GRE configured ----> GRE encapsulation is done ----> Tunnel interface GRE settings with remote destination IP configured ----> Ipsec VPN configured on tunnel interface, packet is sent to remote IPsec tunnel.

This is what I can recollect from the firewall debugs that I once looked sometime back.

Hope this helps.

OK great.

So what kind of IPSEC VPN tunnel would that make it? Route Based/Policy based. Looks like route based to me. ASA's do not seem to support route based VPN's/

Yes, it is a route based VPN on Juniper Firewall.

Should not matter what type of VPN is running on the ASA.

Thanks Hardeep, You have been very helpful throughout. 

Looks like we have some progress but i donno what changed. The Vendor Changed something over the weekend on their side and i was able to ping the GRe tunnel interface on the other side., however they claim they have not changed anything. 

The KB 6126 said that the GRE has to be configured before the IPSEC configuration on the ISG for it to work correctly, im guessing they might have blew up something related to that.

PIM was required on the GRE tunnel to get Mutlcast working and the neighborship was not up all day. I asked them to check if they have it configured it on the correct interface, they claimed that they did and were insistent that i check my ACL. Again about an hour ago, i saw PIM came up automagically on the GRE interface. They haven't responded what was changed yet.

They would not be any Mcast data on the channels for me to check at this time, so i'll have to wait until tomorrow morning to check if it's all working as expected.

Thank you again for your continuous help and support.

Hi Victor,

Glad to know that the setup is working now.

However, for future reference,  it will be good to know what exactly was changed to fix it. (This however could be a challenge as the remote site is not in your control 🙂 )

Best Regards.

Hardeep

Yeah, the remote site is not in my control and thats the big problem. Otherwise this issue would not have been dragged for so long. 

I am suspecting the "Configure GRE first and then IPSEC clause" must have been the issue, atleast thats what i suspect. They were using the GUI to configure and im thinking they did the IPSEC first.

Im still working with them on connectivity issues for traffic thru the tunnel, will probably try and get more info about what they changed. Will surelu update here if i learn something from them.