Public IP in internal NAT with IP Pools - Complex Config

Jtroy · ‎01-01-2019

Hi, I have a small network where all my equipment has private IP addresses (10.x.x.x) and I am using a Fortigate 300C.

I have a special need where I need to use a public IP address (e.g. A.A.A.A) to talk to an equipment that is configured just to reply to that address. My server talks to that equipment by means of a NAT using IP Pool (with only that address A.A.A.A), and it works great. My server is also accessible with a VIP from the Internet and it works great. Problem is that if that particular public IP Address (A.A.A.A) tries to access my server from the Internet the Fortigate doenst seem to know how to handle it... The packets doesnt seem to reach the server and looking through the Fortigate sniffer on that port, I just see SYN, SYN/ACK, RST.

I have tried disabling the NAT, but the only thing that returns the ability of the A.A.A.A address to reach the server from the outside is to delete the IP Pool where it is defined. Just entering this IP Pool again (without any associated Policy) causes the same error.

I am trying to setup a kind of a proxy server that talks to this measuring equipment and is reachable transparently by the same public address, so its important to figure out a way to let A.A.A.A reach my new intermediary server.

[special equipment port 5] <- NAT IP POOL with A.A.A.A. - < [server port 7] <- VIP -< [wan port 9] --- [INTERNET]

I realize that this is unusual and a complex configuration, but after spending many hours, wanted to see if there are any ideas and if the Fortigate can handle this.

What exactly is the treatment of IP Pools by the Fortigate and why would it affect the VIP on another port?

Thanks!

Joe

rohitchoudhary1978 · ‎01-01-2019

Hi Joe,

Its confusing. Can you please elaborate with a network diagram attached.. ...Will love to help

Thanks

Rohit

Rohit K

View solution in original post

jhouvenaghel_FTNT · ‎01-03-2019

Hello,

You mention that "looking through the Fortigate sniffer on that port, I just see SYN, SYN/ACK, RST.

If I understand correctly, the source IP address of the TCP SYN is a public IP address = A.A.A.A and the destination IP address is your internal server.

So the TCP SYN/ACK will have a destination IP address = A.A.A.A which is an IP pool address . The problem is that this session has not been source natted so the kernel would not try to dnat this packet and should simply try to route this TCP SYN/ACK . The issue is that by default ARP reply is enabled in IP pools, so it means that the this destination IP address is seen as "belonging" to the FGT. It means that the kernel would try to route the packet to the FGT itself. So the TCP RST sent from FGT to server

You can try to disable ARP reply in your IP pool, it may help as this IP address would no longer be seen as belonging to the FGT

Thanks

View solution in original post

Jtroy · ‎01-04-2019

Thanks - I think that is the solution. This 300C is running an old version (4.0 MR3 patch 11), hence the feature does not seem to be available in this release.

I will schedule an upgrade to the equipment to the latest version in order to apply this new setting and update with the results. But I totally subscribe to your suggestion. At least in theory, this fits, and should fix it.

Many thanks!

Joe