Skip to main content
Jtroy
Jtroy
New Member
January 2, 2019
Solved

Public IP in internal NAT with IP Pools - Complex Config

  • January 2, 2019
  • 5 replies
  • 25551 views

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

 

 

    Best answer by rohitchoudhary1978

    Hi Joe,

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

    Thanks

    Rohit

    5 replies

    lobstercreed
    lobstercreed
    New Member
    January 2, 2019

    Hi Joe,

     

    Maybe someone else will have a clearer understanding of your post but I'm struggling to follow.  The way I read this part 

    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...

    makes it sound like you're spoofing a public IP that actually exists elsewhere on the Internet, but I don't think that's what you mean.

     

    I have a couple possible theories, but first I'd like to clarify two things...in your topology explanation, is that supposed to be 3 different physical ports involved?  To my knowledge that is not even theoretically possible.  If the destination is on port5, and the source is port9, port7 would not be involved.  So from a policy & object standpoint, you'd need to make sure configurations were correct for port9 --> port5.  This might include that the VIP object needs to have an "interface" of "any" set, which is the default.

     

    Another point that you probably know is that NAT pools have no bearing on inbound traffic.  When the special equipment connects out to the Internet, it uses the NAT pool and of course return traffic (i.e. SYN,ACK step in 3-way handshake) is matched and NAT'd statefully with no need for a VIP.  VIPs are the only objects that have any bearing on inbound traffic, but it sounds like you have that working normally so I'm back to being confused at what your special situation here is that's not working.

     

    If you can clarify I would love to help.  - Daniel Hamilton

    Jtroy
    JtroyAuthor
    New Member
    January 2, 2019

    Daniel,

     

    Thanks for  your reply.  I think you got it.  I am indeed spoofing an IP address that exists in the Internet.  The measuring equipment is configured to just respond to this specific Internet address, but the values it sends are wrong scaled.  Since we can't touch the configuration of that equipment, I have a server that impersonates that IP (through NAT) gets the information from the equipment, scales it correctly and then through a VIP answers to the Internet when questioned for the info, as it was the measuring equipment.  Everything works fine EXCEPT if the IP Address from the Internet is the same one that I am impersonating internally.  Then it doenst work.   Looks to me at something to do with the definition of this IP inside the IP Pools Object.

     

    There are indeed three ports involved in the complete configuration, but I tried to represent everything that is going on, not that it happens at the same time or for the same packet flow.  There is a NAT from port 7 to port 5 and there is a VIP from port 9 to port 7.

     

    The measuring equipment will not need internet access if it just answers to my server and sends the information that is all it is needed from it.  The server will be the one responding queries from the Internet.

     

    I know it's a complex configuration, but a real world problem...

     

    Hope this explains it better.

     

    -Joe

    rohitchoudhary1978
    rohitchoudhary1978Answer
    Visitor III
    January 2, 2019

    Hi Joe,

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

    Thanks

    Rohit

    Jtroy
    JtroyAuthor
    New Member
    January 2, 2019

    Sure.

     

    FInd attached a very basic diagram.  Hope this helps make more sense out of it.

     

    Problem resides in that I need to impersonate a public address internally (NAT with IP Pools), but if that address ever tries to talk to my server, it cant.   As soon as I define that address on the IP Pools, it is not able to reach my server.  The internal spoofing keeps on working and all other addresses access my server fine.

    sajiby3k
    sajiby3k
    New Member
    January 3, 2019

    Hi,

     

    Let's simply your problem if I have understood it correctly - IP addresses are assumptions.

    One computer outside of your control with public IP address - 172.35.16.50

     

    Your server lan ip - 10.10.10.10

    Your server public ip (which is used to reach the server from internet) -172.100.10.10

     

    For allowing 172.35.16.50 to reach 10.10.10.10 from internet - 

     

    Create a VIP - external IP 172.100.10.10, Mapped IP - 10.10.10.10

     

    Now create a firewall rule which does destination nat by using VIP, this rule allows only incoming trafik from the internet to that specific server. 

     

    Src Interface - (wan/internet facing interface)

    Src - Address - 172.35.16.50

    Dst interface - (lan/server's private ip facing interface)

    Dst Address - VIP

    Service - Your required TCP/udp ports

    NAT - NO

     

    If you need to allow outgoing trafik from the internal server to 172.35.16.50 in internet, make another rule with IP pool which does source nat.

     

    Src Interface - (lan/server's private ip facing interface)

    Src - Address - 10.10.10.10

    Dst interface - (wan/internet facing interface)

    Dst Address - 172.35.16.50

    Service - Your required TCP/udp ports

    NAT - Yes, with your IP POOL

     

    It should work. 

    Jtroy
    JtroyAuthor
    New Member
    January 3, 2019

    sajiby3k,

     

    You understood the first part.  With 172.35.16.50 (following your example) accessing  my  Server with a VIP.   That is configured and it works.  Now the second part is not my server outgoing traffic and I will try to explain that part more thoroughly:

     

    I have a measuring equipment with an internal address (lets call him B) that is configured (outside my control to change) to just answer to that one public address (172.35.16.50).  I want my server (lets call him A) to extract info from that equipment (B) and not let B talk to anyone else.   The only way B will respond to A, it's if I do a NAT internally and make B think it's 172.35.16.50 talking to it.   This works doing a NAT with IP Pools, and it works well. 

     

    But when I set the IP Pool with that Public address, and the same address tries to enter with the VIP, it doesn't work...

     

    To summarize, and to expand your example, we have:

     

    X (Any Public internet)

    Y (Specific Public IP 172.35.16.50)

    B (Measuring Equipment 10.10.10.50 GW 10.10.10.1 (port 5) HardCoded to only answer to address Y)

    A (My server 10.10.20.20 GW 10.10.20.1 (port 7) )

     

    I have VIP - external IP 172.100.10.10, Mapped IP - 10.10.20.20  (works)

    and I have a policy with when 10.10.20.20 goes to 10.10.10.50 to NAT using IP Pool specifying 172.35.16.50 as source.  this works.

     

    Now with both rules active, if X access through the WAN using the VIP to my server, everything works fine.  If the real Y address comes through the WAN, it clashes with the IP Pool and it doesn't work.

     

    How can  I make my server the transparent man in the middle?

     

    Hopefully this time it's more clear...

     

    Joe

     

     

     

    jhouvenaghel_FTNT
    Staff
    jhouvenaghel_FTNT
    Staff
    January 3, 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

    Jtroy
    JtroyAuthor
    New Member
    January 3, 2019

    This makes a lot of sense with what I am seeing.  How do you turn off the arp reply from the IP Pools?  Any way to do it on the GUI or it's a CLI trick?

     

    Can this break anything else?  I wouldn't expect it to... Since the address on the IP Pools in not a local subnet, hence no one needs to reach it via ARP...

     

    BIG THANK YOU for the suggestion!

     

    -Joe 

    jhouvenaghel_FTNT
    Staff
    jhouvenaghel_FTNT
    Staff
    January 3, 2019

    you should be able to disable arp-reply in GUI and CLI when editing the ippool. In CLI , just do a get to see the parameters.

     

    Arp-reply is a "new" parameter  since 4.x which was added for a customer interested to source NAT packet with an IP address existing on an external station. Before this, arp-reply was by default enabled. After this new parameter was introduced, customer could disable arp-reply to not have any conflict with an IP address belonging to a station and to the FGT

     

    In your case, I don't believe there is any problem to disable arp-reply. To my knowledge having arp-reply enabled is useful for example in situation like you have : to detect tcp syn/ack from server with a destination IP address equal to an IP pool address with the tcp syn from client not source natted . This situation should not arrive in most common cases.

     

    As you are in a special case, I think that disablng arp-reply should help

    Jtroy
    JtroyAuthor
    New Member
    January 4, 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

    Terms & ConditionsAccessibility statement