Skip to main content
veechee
veechee
New Member
May 6, 2013
Question

How to set the interface for the FortiGate to use as ' internal' ?

  • May 6, 2013
  • 7 replies
  • 11849 views
I deployed one FortiGate 60C using VLAN interfaces (a domain VLAN and a guest VLAN). Everything works fine between clients and servers across the VPNs, however, I just recently realized that the FortiGate itself cannot reach clients and servers across the VPNs. This means the FortiGate can' t reach FSSO across the VPN, or a mail server. The other FortiGate' s at the same company don' t use VLANs and have no such troubles, How do I make the FortiGate aware of what interface to use by default for " internal" functions? Right now even ping fails from the FortiGate.

    7 replies

    veechee
    veecheeAuthor
    New Member
    May 8, 2013
    Bump. Anyone? To restate the issue another way: With my IPSec interface-based site-to-site VPNs - where the ' internal' interface is my Windows domain network, ping/email/etc from the FortiGate to anything at the other sites works fine. This behaviour is as expected and needed. - where the ' internal' interface is not used itself, and instead has a VLAN sub-interface for the Windows domain network exists for routing inside the local site, while the clients and servers at that site can ping/email/file share/etc to anything at the other sites, the FortiGate itself cannot. This behaviour not as expected and needed. Yet another way: If I specify the mail server is 10.99.99.10, which is at another site, the FortiGate knows where that is from the static routes for that interface-based VPN, however, it tries to reach it using ' internal' , but the FortiGate itself doesn' t even have an IP on that interface to send from, so it can' t reach the mail server. How do I make the FortiGate aware of what interface it should use by default for these core functions?
    emnoc
    emnoc
    New Member
    May 8, 2013
    A snapshot of your routing-table ( get router info ) would be better in your description but if I' m hearing you correctly........ The fortigate does route out that way , nor use the interface " internal" in the destination routing decision making. So you would have 2 options the 1st one is challenging; 1: Tell the fortigate to use interface X and ip_address blah blah 2: maybe and only a some way with NAT tricks and dst/port of the far end , you could tell it to map into a address with traffic to the remote subnet and for it to use the tunnel or 3( this just cam up after I was thinking of #2 ) have you looked at maybe a VIP or ippool creation? Now I never had to deal with these issues and these ideal/suggestion are just that ideals & suggestions Also what services at the remote-subnet does the fortigate need to access? Maybe you have an alternative method to get the same outcome.
    veechee
    veecheeAuthor
    New Member
    May 8, 2013
    The command ' get router info' doesn' t return anything. I checked on the device having the routing problem and on my head office box, both are the same. 
    CHN_FGT60C~ # get router info    CAN_FGT60C~ # get router info
    I have attached a screen snip showing the static route for the VPN. Ping from head office (CAN) to remote office (CHN): 
    CAN_FGT60C~ # exec ping 10.20.x.1    PING 10.20.x.1 (10.20.x.1): 56 data bytes  64 bytes from 10.20.x.1: icmp_seq=0 ttl=255 time=210.9 ms  64 bytes from 10.20.x.1: icmp_seq=1 ttl=255 time=210.0 ms  64 bytes from 10.20.x.1: icmp_seq=2 ttl=255 time=210.1 ms  64 bytes from 10.20.x.1: icmp_seq=3 ttl=255 time=212.2 ms  64 bytes from 10.20.x.1: icmp_seq=4 ttl=255 time=210.0 ms    --- 10.20.x.1 ping statistics ---  5 packets transmitted, 5 packets received, 0% packet loss  round-trip min/avg/max = 210.0/210.6/212.2 ms
    Ping from remote office (CHN) to head office (CAN): 
    CHN_FGT60C~ # exec ping 10.51.x.1    PING 10.51.x.1 (10.51.x.1): 56 data bytes    --- 10.51.x.1 ping statistics ---  5 packets transmitted, 0 packets received, 100% packet loss
    Why the different behaviour?! From a client at CHN I can ping the head office FortiGate just fine: 
    C:\Users\X>ping 10.51.x.1    Pinging 10.51.x.1 with 32 bytes of data:  Reply from 10.51.x.1: bytes=32 time=210ms TTL=254  Reply from 10.51.x.1: bytes=32 time=216ms TTL=254  Reply from 10.51.x.1: bytes=32 time=210ms TTL=254  Reply from 10.51.x.1: bytes=32 time=210ms TTL=254    Ping statistics for 10.51.x.1:      Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),  Approximate round trip times in milli-seconds:      Minimum = 210ms, Maximum = 216ms, Average = 211ms
    There is no NAT involved here. No NAT traversal on the IPSec VPNs even; they are dedicated static IPs at each end point. I need two services to work from the FortiGate itself to head office servers: SMTP and FSSO. It would be nice for ping to work too for periodic performance measurement (e.g., latency) and troubleshooting. And beyond that I would really like it to work the same as my other FortiGates. I don' t want it to be complicated; the main reason I introduced VLANs was so that I could eliminate the separate interfaces for wireless access.
    veechee
    veecheeAuthor
    New Member
    May 8, 2013
    Another piece of information: I do not experience this issue with a FortiGate on a VLAN reaching devices on the same VLAN in the same site. So I can ping the switch, clients, servers at the same site without issue, and also access local SMTP. Since my routing table is correct - the clients couldn' t access anything if it wasn' t, this is why I summarize the problem as the FortiGate not knowing which of it' s IP addresses to use to access an IP address at the other site. And to prove my routing table is functional, if I force the source address I can ping across the VPN: 
      CHN_FGT60C~ # execute ping-options source 10.20.x.1    CHN_FGT60C~ # execute ping 10.51.x.1    PING 10.51.x.1 (10.51.x.1): 56 data bytes  64 bytes from 10.51.x.1: icmp_seq=0 ttl=255 time=210.6 ms  64 bytes from 10.51.x.1: icmp_seq=1 ttl=255 time=210.3 ms  64 bytes from 10.51.x.1: icmp_seq=2 ttl=255 time=210.1 ms  64 bytes from 10.51.x.1: icmp_seq=3 ttl=255 time=210.3 ms  64 bytes from 10.51.x.1: icmp_seq=4 ttl=255 time=215.2 ms    --- 10.51.x.1 ping statistics ---  5 packets transmitted, 5 packets received, 0% packet loss  round-trip min/avg/max = 210.1/211.3/215.2 ms
    rwpatterson
    rwpatterson
    New Member
    May 8, 2013
    Couldn' t you just define an IP address on the VLAN (on the FGT in question)?
    veechee
    veecheeAuthor
    New Member
    May 8, 2013
    rwpatterson, It has one! What I just forced it to use I want it to use all the time!
    veechee
    veecheeAuthor
    New Member
    May 10, 2013
    I' ve opened a ticket with support to help me get this figured out. I will post the resolution.
    itsTrust
    itsTrust
    New Member
    March 23, 2018

    veechee wrote:
    I' ve opened a ticket with support to help me get this figured out. I will post the resolution.
    Hi everyone and sorry to bump up this old post, I have exactly the same problem with FortiGate 200D and the last FortiOS version available: v5.6.3 build1547 (GA).

     

    Is there any way to set the source IP of the FG as the "internal" interface only for ICMP requests?

     

    I've searched around but didn't find anything related.

     

    Thanks in advance!

    veechee
    veecheeAuthor
    New Member
    May 14, 2013
    Support solved my issue for SMTP: " Technical Tip : How to control/change the FortiGate source IP for self-originating traffic : SNMP , Syslog , FortiAnalyzer , Alert Email , FortiManager" Unfortunately I cannot achieve the same thing for FSSO unless I upgrade to FOS 5.0 or start using multiple phase 2' s for my IPSec VPNs, so I will live without that for now.
    Terms & ConditionsAccessibility statement