Virtual IP source address

[joebrug]

Using 5.2.2

For years, we've had load balancing set up on our terminal servers in house using the simple microsoft NLB (172.16.1.45 is address for our NLB addres, 172.16.1.45 is also the secondary ip address on multiple TS servers).

Traditionally, we had a simple NAT set up for an external IP to point to 172.16.1.45. This worked just fine and users would log in on either of the TS's without a problem.

Since implementing the fortigate 200d a few weeks ago, we've noticed that all users are only connecting to ONE of the TS's. (TS1)

I simply created a Virtual IP with the external address and 172.16.1.45 as the internal address, then created a rule that allows traffic from source = ALL to Destination = TS Load Balancer, with only RDP (port 3389) allowed.

If I do a netstat -n on the terminal servers, all of the connections are showing the IP address of the Fortigate, instead of the clients actual external IP address. Even connecting DIRECTLY to a TS (without using the NLB), shows the fortigate interface as connected.

TCP 172.16.1.44:3389 172.16.0.2:51606 ESTABLISHED TCP 172.16.1.44:3389 172.16.0.2:65133 ESTABLISHED

How/why? 172.16.0.2 is the fortigates LAN interface.

Therefore, I believe the MS NLB is just assuming all traffic is coming from the same IP, so its going to put it on the same server as the others.

I found this legacy doc http://docs-legacy.fortinet.com/cb/html/index.html#page/FOS_Cookbook/Firewall/cb-firewall-dnat3.html that says at the bottom in a warning window: "If you select NAT, the source address is changed to the internal interface address. Normally, you would not want to perform source NAT since this has the affect of hiding the actual source address of the sessions."

Is there a way for that not to happen?

Thanks

[scheehan_FTNT]

Hi,

It would be helpful if you provide session info. Please remove/replace any sensitive info like public IP address

# diag sys session filter dport 3389

# diag sys session li

[emnoc · Accepted solution]

Have  you ran a diag debug flow?

(e.g from cli )

diag debug  reset

diag debug en

diag debug flow filter dport 3389

diag debug flow addr 172.16.1.45

diag debug flow show console enable

diag debug flow trace start 100

Then have some one  attempt a connect. I believe you have  nat enabled on the fw-policy and that's why the SRC is being mapped to  the LAN interface . When your done, disable the diag debug ( diag debug disable )

Hope that helps.

[joebrug]

emnoc wrote:

 I believe you have  nat enabled on the fw-policy and that's why the SRC is being mapped to  the LAN interface .

Turning NAT off of the WAN > LAN policy fixed it! I misunderstood the need for this, I turned it off on all WAN > LAN policies :) Thanks!