Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
freaky
New Contributor

Other router for other subnet / ICMP redirect

Hi, a customer of ours got a separate connection with it' s own router for site-to-site VPN (managed through an ISP). The router is patched in directly to the internal network and the FGT is the default gateway. We have added the routes to the FGT and created firewall rules from internal to internal. We can get traffic out, that works fine as the firewall rules allow it. Traffic also flows like this: (192.168.1.51 (source / client)) 192.168.1.254 (FGT) 192.168.1.253 (router from ISP) 192.168.2.254 (upstream) 192.168.2.1 (upstream server) packet back: (192.168.2.1 (source)) 192.168.2.254 192.168.1.253 192.168.1.51 So far so good. Traffic back however is where the issue starts. I think this is because the incoming packet (creating the session in the firewall table) is never seen by the FGT. Since we' re out of ports, and we don' t want to firewall that traffic anyways, we' d like the FGT to just send a ICMP redirect letting the client know that subnet is accessed by another local router. Is that possible?
8 REPLIES 8
rwpatterson
Valued Contributor III

What does a trace route from the other direction show?

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
ede_pfau
SuperUser
SuperUser

Your routing is at fault, and rather than tweaking the FGT to issue ICMP redirects you should fix the routing in the first place. Just install a route on the client PC telling it that the destination subnet is reachable via .1.253. Traffic to the remote subnet will now go directly from .1.51 to .1.253 (L2, no routing), be routed over the VPN to the destination. The FGT will be completely out of the data path, as it should be.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
freaky
New Contributor

@rwpatterson: will have to request again from the other side, lost it. Quite sure it died after their VPN router. @ede_pfau: How is my routing at fault? ICMP redirect isn' t exactly new (I already used it in 1998 or something) and I don' t really want to enter manual routes on dozens of computers, they' re not all domain joined. ICMP redirect wasn' t invented for nothing :). Here' s a short explanation of ICMP redirect: Redirect Redirect requests data packets be sent on an alternative route. ICMP Redirect is a mechanism for routers to convey routing information to hosts. The message informs a host to update its routing information (to send packets on an alternate route). If a host tries to send data through a router (R1) and R1 sends the data on another router (R2) and a direct path from the host to R2 is available (that is, the host and R2 are on the same Ethernet segment), then R1 will send a redirect message to inform the host that the best route for the destination is via R2. The host should then send packets for the destination directly to R2. The router will still send the original datagram to the intended destination. However, if the datagram contains routing information, this message will not be sent even if a better route is available. RFC1122 states that redirects should only be sent by gateways and should not be sent by Internet hosts.
emnoc
Esteemed Contributor III

We all know how icmp redirect works, redirections opens you open to a host of numerous attacks and other possibilty & vulnerabilities. Also ICMP is generally flaw when it comes to security and has an expiration so to speak. Why don' t you do this instead; Much simpler, better, more efficient and more meets best practices. Then construct your policies from internal to WAN1 and internal to WAN2. WAN2 could also been done on a subinterface and with suing 8021q

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
ede_pfau
SuperUser
SuperUser

OK, different solution proposal. Keep your clients' default route to the FGT and let the FGT route traffic to the second router. Setup: - change the second router' s internal IP address to some address outside the LAN address space, like 10.11.12.1/29. - create a secondary IP address on the internal (LAN facing) port of the FGT (that' s why we need a small subnet) - set up a route on the FGT with destination=remote subnet, gateway=second router - set up a policy on the FGT, from ' internal' to ' internal' , allow this traffic This setup avoids the asymmetric routing which you encounter now.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
freaky
New Contributor

Hmm hadn' t thought of doing it with multiple addresses on one interface, might try that :). Would have created a vlan interface, but their switch doesn' t support vlan' s :(. Thanks for the re' s.
rwpatterson
Valued Contributor III

Doesn' t the secondary IP force you to a /24? Never mind. It defaults to that. Never had to change it.... ;)

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
ede_pfau
SuperUser
SuperUser

Yeah, funny. There' s hidden life in a FGT... Actually a /30 would do, just 2 addresses. This will minimize possible side effects while using this transfer net.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors