Screen OS

 

Hello Contributor/Expert and all members,

 

I've a weird incident on my VPN configuration. Would appreciate if someone can contribute some knowledge and expertise.

 

The scenario is: 

 

- Server in HQ need to be connected to other site i.e: site A

- HQ network protected by Fortinet 200b

- Since SSG20 VPN cannot configure behind firewall, then I've bypass the firewall by configuring another IP from the main router (connect to ISP network)

- Now SSG is connected from the main router and I've configure Static IP in Untrust zone (eth0)

- For Bgroup0 (bond with eth2,3,4) - I've assgined the same subnet IP use by server environment i.e: 10.10.10.x/24

- The actual network for servers are connected to the network in Fortinet (GW 10.10.10.254/24)

- The reason i'm using the same subnet with network in Fortinet is to ensure the network in SSG can reach the server environment

- The same network IP in bgroup doesn't solve the problem so I plug the cable at eth4 (same bgroup) and connect to the switch which connect to the network server and now the connection is establish (both site can ping each other)

- Last step is to create VPN to site B 

- From SSG, I can ping to the server i.e: 1.1.2.1/24 and gateway at Fortinet 1.1.2.254/24

 

At site B

 

- Dynamic IP (configure at Eth0) - untrust

- 10.10.20.254/24 assigned to bgroup

- VPN created to Site A

 

VPN objective is to ensure computer at site B can access the server at site A. Once VPN created, Site A bgroup (trust) IP: 10.10.10.254 can ping to Site B (trust) 10.10.20.254 **means the VPN are establish between both site. But the weird thing is Site B cannot reached server at Site A but Site B can reached SSG. 

 

My taughts if the network in the same subnet and environment, it is supposed can reach each other. Or it is not possible to join network from the Fortinet and use the same IP configure in SSG?

 

Appreciate your advice and contribution

 

Regards,

 

 

 

It is probably a routing issue.  Sounds like the server is probably sending the out a different path than what it came in on.

Hi Rseibert,

Thanks for your kind input.

The routing issue at which site/router? Do i need to add routing at server? The server is using Windows server. Currently the server network card are pointing to fortinet router gateway 1.1.2.254/24. But if it is routing issue, the weird part is the trust zone at SSG box can ping to the server but the trust zone from site B cant reach to the server ip but it can reach to SSG trust zone at site A

Hi,

 

A simple test to narrow down on a routing isue would be to NAT the traffic before it leaves the SSG.

On the policy that permits traffic from Site-B to the server, enable Src-NAT and use the SSGs interface IP to NAT the traffic. This will mask the Site-B subnet behind the SSGs internal interface IP.

 

If this works, you can either leave the NAT in place or sort out the routing issue - maybe route added on the server, pointing to SSG as the gateway to reach Site-B.

 

Hi Gokul,

 

Thanks for your advice.

 

Do i need to NAT the Untrust port? Or the port which facing the VPN tunnel (trust zone)?

 

My config: port 0 (un-trust) and bgroup 0 (trust).

 

I've enable the policy - untrust (side B) to trust (LAN to server) which changed the action indicator color from green to blue

 

 

Hi,

 

Use the interface-IP that faces the server.

In simple terms, on the policy that allows traffic From Remote To Server, enable Src-NAT, select 'use egress interface IP' option.

 

The interface IP (bgroup 0-trust zone) which facing the server is in NAT mode. And I've enable the Src_NAT in the policy from remote (Site B trust Zone) to Server (Site A trust Zone) still no luck. 

 

Regards.

Hi All,

 

A heads up on the issue that I'm currently facing.

 

If I do the traceroute from remote site to Site A, the SSG box at remote site can reached the LAN (bgroup-trust) IP. 

 

SSG140-> trace-route 10.10.10.27 from bgroup0
Type escape sequence to escape

Send ICMP echos to 10.10.10.27, timeout is 2 seconds, maximum hops are 32, trace from bgroup0/0
1 0ms 1ms 0ms 10.10.20.254
2 17ms 17ms 16ms 10.10.10.27

 

But if I trace-route from remote to the server, it failed to communicate

 

SSG140-> trace-route 10.10.10.7 from bgroup0
Type escape sequence to escape

Send ICMP echos to 10.10.10.7, timeout is 2 seconds, maximum hops are 32, trace from bgroup0/0
1 1ms 1ms 0ms 10.10.20.254
2 41ms 15ms 15ms 10.10.10.27
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *

 

At Site A, the SSG box can reached the server since it is in the same subnet:

 

ssg20-wlan-> trace-route 10.10.10.7 from bgroup0
Type escape sequence to escape

Send ICMP echos to 10.10.10.7, timeout is 2 seconds, maximum hops are 32, trace from bgroup0
1 5ms 2ms 2ms 10.10.10.7
Trace complete

 

It seem like the SSG box in Site A didnt allow the communication from remote site to the server. But it allow the communication from remote LAN to Site A LAN via VPN tunnel.

 

Do I need to add addtional VR routing to enable Bgroup (LAN) to allow communication from remote site to the server IP?

 

 

Hi,

 

If NAT-ing did not resolve the problem, more likely it is not a routing issue on the server LAN.

 

Does Site-A have the necessary policies to allow this traffic?

If the config looks good, you can collect a simple debug on Site-A FW:

 

undebug all

clear db (will clear the exisiting debug data)

set ff src-ip <bgroup ip of the Site-B firewall> dst-ip <ip of the server>

set ff src-ip <ip of the server> dst-ip <bgroup ip of the Site-B firewall>

debug flow basic

<<ping server from siteB FW bgroup>>

<<Press Esc once it fails>>

get db st

 

The log printed by the last command will give an idea about traffic processing

 

Hi Gokul,

 

I've run the cmd as your advice and unfotunately no log printed after I've run the last cmd

 

SSG140-> set ff src-ip 10.10.10.27 dst-ip 10.10.10.7
filter added
SSG140-> set ff src-ip 10.10.10.7 dst-ip 10.10.10.27
filter added
SSG140-> debug flow basic
SSG140-> ping 10.20.5.7
Type escape sequence to abort

Sending 5, 100-byte ICMP Echos to 10.20.5.7, timeout is 1 seconds
.....
Success Rate is 0 percent (0/5)
SSG140-> All debug off

SSG140-> get db st
SSG140->
SSG140->
SSG140->

 

Is there any steps that I've missed out?

 

Thanks

 

Regards.

Hi,

 

First, the filter is set for a different IP, while you are trying to reach 10.20.5.7. The filter will nto capture this traffic.

As per your previous post, isn't the server IP 10.10.10.7.

 

Also, the debug should be run on the Site-A firewall, which would be the SSG-20:

 

<<<<<<<<<<<<<<<<<At Site A, the SSG box can reached the server since it is in the same subnet:

ssg20-wlan-> trace-route 10.10.10.7 from bgroup0>>>>>>>>>>>>>>>>

 

My Apologize..

 

Wrong place to run ping earlier.

 

Attached is the debug result

 

If you've any thoughts and advice feel free to share, much appreciated!

 

Regards

 

Hi,

 

As per the debug, the Firewall is handling the packet as expected.

 

  tunnel.1:10.10.20.254/49292->10.10.10.7/1024,1(8/0)<Root>   *** Packet reaching the firewall through tunnel

Permitted by policy 320002  ********** Allowed by default policy

packet send out to d48564438f9a through bgroup0 ********** Sent out to the LAN.

 

But the response packet is not seen.

 

Do you still have the Src-NAT configuration in place? Because, the Firewall is not NAT-ing the traffic as per the debug.

Also, is there a specific polic that you have configured for thsi traffic? Because, the traffic here is being allowed by the Default policy and not a specific policy (320002 is the default permit)

 

I would suggest:

 

<<<On SSG-20>>>

 

1. Create a new policy to allow this traffic

2. enable src-NAT, use Egress interface IP option on this policy

3. Test traffic flow

4. Collect debugs again if issue is not fixed (you may need to add more filters, to include the NAT IP as well)

 

Dear Gokul,

 

Yes, the Src-Nat config still in place. Since the policy is the same as tunnel policy remote site (untrust-bgroup siteA) to server lan (bgroup site B), I've just enable the Src-Nat in the same policy as VPN tunneling. 

 

Does it make sense?

 

Regards.

 

Dear Gokul,

 

Thanks for your kind help and advice.

 

I've managed to get the communication established. Now I can ping to the server from site B

 

Solution: On the previous setup, I've enable the Src-NAT at VPN policy (untrust - trust). Addtional policy must be created from trust to trust zone (intra-zone policy) and enable the Src-NAT on that policy 

 

Regards.

You are welcome.. glad that the setup is working now.

Sounds like a routing problem indeed.

 

As mentioned earleir, you may leave the NAT in place or add a route on the server, pointing to the FW for reaching the remote subnet.

 

Please mark this thread as resolved if you think the setup is good now.

 

Dear Gokul,

 

Will do as per your advice.

 

Have a pleasant day ahead!

 

Regards,

Afif