Skip to main content
westekim
westekim
Explorer
June 22, 2015
Question

NAT problem: Private address on WAN and Public address on Internal

  • June 22, 2015
  • 3 replies
  • 7018 views

I have a FortiWifi 90D in an environment as follows:

 

ISP Gateway not under my control: 10.10.40.1/255.255.255.252 (routing 194.x.x.64/255.255.255.224 to 10.10.40.2)

Wan IP: 10.10.40.2/255.255.255.252

Internal1: 192.168.6.1/255.255.254.0

Internal2: 194.x.x.65/255.255.255.224

 

The idea behind our somewhat exotic configuration is to use all of our public IP addresses behind our firewall.The problem with it is that the FortiWifi doesnt have a public IP address on the WAN interface.

Before the FortiWifi we had a Linux server with Shorewall acting as a firewall and there I just set up some NAT:ing to make it work.Some of it I can replicate on the FortiWifi but not all.

 

1. All the traffic from Internal1 to WAN is NAT:ed to show 194.x.x.65 as source. This was not a problem on the FortiWifi.

 

2. The traffic from the firewall to WAN was also NAT:ed to show 194.x.x.65 as source. This I could not figure out how to do on the FortiWifi. (example traffic: FortiWifi->FortiCloud)

 

3. All the traffic to 194.x.x.65 should be received by the Internal2 interface. On the old firewall this was just done by allowing the traffic to be routed and was then received by the internal interface with the public address. This was partly solved on the FortiWifi by using a VIP to map 194.x.x.65 to 10.10.40.2. But now 194.x.x.65 cant be accessed from the internal interfaces. (example traffic: SSL VPN)

    3 replies

    rwpatterson
    rwpatterson
    New Member
    June 22, 2015

    I'll bet you have that IP address in an IP pool. Any addresses in an IP pool are basically removed from any FGT routing. I had run into this in the past and it is a real PAIN. Not documented anywhere (I could find at the time). As a quick test, change that IP pool address to another IP and see if PINGs start.

     

    My two cents. Your mileage may vary.

    westekim
    westekimAuthor
    Explorer
    June 23, 2015

    194.x.x.65 is in a pool, yes. Thats how "All the traffic from Internal1 to WAN is NAT:ed to show 194.x.x.65 as source." was done. But I'm not sure what you mean I will solve by moving this pool to another address.

     

    194.x.x.66 is free for that but after a quick test it turned out that the SSL VPN stopped working when I did this so I had to change it back and I'll do some more testing after office hours. The tunnel mode just stopped working and I could not figure out why, but when I cahn ged the pool back to .65 it started working again.

     

     

     

    westekim
    westekimAuthor
    Explorer
    June 23, 2015

    194.x.x.65 is in a pool, yes. That's how "All the traffic from Internal1 to WAN is NAT:ed to show 194.x.x.65 as source." was done. But I'm not sure what you mean I will solve by moving this pool to another address. 194.x.x.66 is free for that but after a quick test it turned out that the SSL VPN stopped working when I did this so I had to change it back and I'll do some more testing after office hours. The tunnel mode just stopped working and I could not figure out why, but when I changed the pool back to .65 it started working again.

     

    Also it did not seem to fix any of the problems (2 & 3). I still could not reach 194.x.x.65 from the internal interfaces but I guess that I need to remove the VIP also.

     

    My problem here seems to be that there is no documented way to configure what happens with the local traffic inside the FortiWifi. I can't set 194.x.x.65 as the source address for the packets originating from the device. They automatically get the 10.10.40.2 address. And I cant make a policy for accepting packets that should be routed and then received by the internal router interface.

    Terms & ConditionsAccessibility statement