Can I change VPN administrative distance without creating trouble?

[icom]

Hi, 

I have problems with creating a Site-to-site between a 60E(behind nat/router and a old Juniper FW. 

The fortigate is claiming the tunnell is up and the same about the juniper, but no traffic is passing

last log entry on juniper:IKE 85.x.x.x Phase 2 msg ID e17d3fc6: Completed negotiations with SPI 694e0051, tunnel ID 7, and lifetime 3600 seconds/0 KB.

On both Fortigate and Juniper i created firwall policies and added static routes.

Is this about interface administrative distance? 

On my fortigate my vpn interface is having a distance of "10" and my 0.0.0.0/0 is set to 5 (WAN1)

Can is change my vpn distance without causing any trouble? I wonder if this is the problem.. that my fortigate is trying to route through WAN1 and not VPN/IPSEC.

[Toshi_Esumi]

Unless you want to route everything (0/0) into the tunnel, it shouldn't have anything to do with your problem. You must have set more specific static routes into the tunnel.

You need to sniff traffic on both ends to see where it's going or why it's dropped  (flow debug on fortigate, Juniper FW probably has similar capability) if it's dropped somehow.

[ericli_FTNT]

icom wrote:

Hi, 

I have problems with creating a Site-to-site between a 60E(behind nat/router and a old Juniper FW. 

The fortigate is claiming the tunnell is up and the same about the juniper, but no traffic is passing

last log entry on juniper:IKE 85.x.x.x Phase 2 msg ID e17d3fc6: Completed negotiations with SPI 694e0051, tunnel ID 7, and lifetime 3600 seconds/0 KB.

On both Fortigate and Juniper i created firwall policies and added static routes.

Is this about interface administrative distance? 

On my fortigate my vpn interface is having a distance of "10" and my 0.0.0.0/0 is set to 5 (WAN1)

Can is change my vpn distance without causing any trouble? I wonder if this is the problem.. that my fortigate is trying to route through WAN1 and not VPN/IPSEC.

What did you get from "diag vpn tunnel list"?

[emnoc]

I 'm a heavy   SRX  guy ;)

1: is this a rt-base vpn

2: do you have a st.tunnel interface on the  SRX

3: Have you applied a route ( rt-based ) on the SRX and  FGT for the traffic in the  encryption-domain

4: what are your selector-id ( quad 0s or src/dst specific ......) e.g  1.1.1.0/24 or 0.0.0.0/0:0

5: http://socpuppet.blogspot.com/2013/09/vpn-ikev2-juniper-to-fortigate-routevpn.html

6: I woud run a diag debug  flow on the FGT and validate any simple errors ( lack of fwpolicy, deny,  spoof, route lookup )

dump your config from the FGT/SRX and we can  review it

[ede_pfau]

No, the most matching route is chosen, and the distance is only compared if 2 or more routes are available.

But, you could be right with your assumption that the traffic is routed out of the WAN interface IF the route pointing to the tunnel is wrong - mistyped address or wrong netmask. In this case, the default route is the only suitable one and will be followed.

[rwpatterson]

Is this about interface administrative distance?  On my fortigate my vpn interface is having a distance of "10" and my 0.0.0.0/0 is set to 5 (WAN1)   Can is change my vpn distance without causing any trouble? I wonder if this is the problem.. that my fortigate is trying to route through WAN1 and not VPN/IPSEC.

The distance to the default gateway should always be the highest since it is the last path chosen. All the tunnels should have a lower distance. Swap those two and as long as no other static routes are present, you should be good. Alternatively, just make the static distance higher than any other you have defined.

[icom]

Please see attached fortigate config. 

The juniper unit it's not mine, so just now I cannot access the FW and extract config. 

The only thing I remember are that we did run the Route VPN wizard. 

We dont have st0.0 internface, but we created "tunnel.8" (7 other tunnels) and mapped this against the gateway/ipsec connection. 

[icom]

I got the config from the juniper ssg5. removed data and firewall rules for other tunnels. 

see .txt 

[emnoc]

Your missing a lot of diagnostic output. Again  ;

diag debug flow

diag vpn tunnel list

get router info routing all | grep 172.22

I would start with those three on the FGT side.

On the  Juniper device I would execute the 3 items below

show route

show security ike security-associations

show security ipsec security-associations

{ SPI  indexs should match SRX and FGT if thPH2 is really up )

Since you caught up on routing I would  run a ping from  192.168.22.xxx to 172.22.22.xx and  while that's running from a internal host I would monitor packets leaving the FGT

diag sniffer packet metro

Skiming thru the cfgs it all looks good, I just don't like "name" address objects in the vpn tunnel  configurations

[icom]

i'm administrating this through forticloud. holy he** this is slow : O 

------------------------------------------------------ name=Metro ver=1 serial=5 192.168.1.159:0->(behind nat) 85.x.x.x:0 (WAN IP JUNIPER) bound_if=4 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/0 proxyid_num=1 child_num=0 refcnt=13 ilast=15 olast=10075 ad=/0 itn-status=2 stat: rxp=0 txp=0 rxb=0 txb=0 dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=Metro proto=0 sa=1 ref=2 serial=1 src: 0:192.168.22.0/255.255.255.0:0 dst: 0:172.22.22.0/255.255.255.0:0 SA: ref=3 options=10226 type=00 soft=0 mtu=1446 expire=1848/0B replaywin=1024 seqno=1 esn=0 replaywin_lastseq=00000000 itn=0 life: type=01 bytes=0/0 timeout=3298/3600 dec: spi=841d9218 esp=3des key=24 742e5be2abc6526fcff689e82135d62b78f0c88e4c887c99 ah=md5 key=16 115215c98956dd0d3004988b7821fe23 enc: spi=694e01d7 esp=3des key=24 0be392fc9cb4d58e3aaedec540462dcb018bab2d15fc5f96 ah=md5 key=16 c0c79d2ea9ee55ec3922eb29162fc5d6 dec:pkts/bytes=0/0, enc:pkts/bytes=0/0

S 172.22.22.0/24 [10/0] is directly connected, Metro