Skip to main content
Wayupnorthguy
Wayupnorthguy
Explorer
October 4, 2022
Solved

Site to Site Fortigate private network over IPSEC, Allow SMTP outbound from single device

  • October 4, 2022
  • 4 replies
  • 5555 views

I have a private point to point network over IPSEC VPN.  I'm trying to allow only SMPT sendmail service from a single client on one end to a host on the Internet via the WAN interface.  I've created an outbound FW rule to allow SMTP port 25 to a FQDN (smtp.gmail.com) from the internal client with NAT enabled using the outside WAN interface IP.  I've also created an inbound rule allowing ALL traffic from smtp.gmail.com to that specific client.
I can telnet from the CLI to port 25 on the smtp server but I cannot do the same from the client.
I've enabled and disabled NAT on the inbound side with same results.
I'm pretty new to Fortigate but have experience with other firewall and policy products.

Best answer by Wayupnorthguy

I found that the FQDN address that I created resolved to a different IP then what I was using in the Telnet command.  When I changed that I was able to connect.  Bottom line is that if you have a client that cannot resolve addresses due to DNS being blocked...you have to use the known IP and that IP has to match the FQDN....or don't use FQDN and just put the IP address in.  Live and Learn.

 

4 replies

aionescu
Staff
aionescu
Staff
October 4, 2022

Hi @Wayupnorthguy 

 

Welcome to the community!

 

Can you please explain the topology? Is the IPsec tunel between the client and the FortiGate or between the FortiGate and the SMTP server?  Since is google smtp I would expect it to be reachable via the Internet so the IPsec is between the client and the firewall. 

 

As always, looking at the traffic flow, we can get some insight on how it is handled by the firewall. 

While trying to telnet from the client you can run the following commands and share the output:

 

diagnose debug enable

diagnose debug flow filter addr x.x.x.x  <----where x.x.x.x is the source IP

diagnose debug flow filter dport 25

diagnose debug flow trace start 100

 

You can use the info from Technical Tip: Using filters to clear sessions on ... - Fortinet Community to filter/clear any existing session (if any) so the debug will show how the session is created. 

Based on the output, you can then confirm if the traffic is flowing as expected (related to the involved interfaces and policies).

 

To disable the debug:

diagnose debug disable

Wayupnorthguy
WayupnorthguyAuthor
Explorer
October 7, 2022

This was most helpful in tracking down the source of the data blocking.

Wayupnorthguy
WayupnorthguyAuthor
Explorer
October 4, 2022

Wayupnorthguy_0-1664917429758.png

Very basic site to site private network.  The network on the left is behind NAT and "dials" to the network on the right.  This part works fine.  The clients on the left access the NMS on the right and the NMS is set to send alerts via SMTP to various email recipients.
I ran the debug and tried to telnet from the NMS server.  I got no output on the CLI (note I'm accessing the CLI from the GUI)

Wayupnorthguy
WayupnorthguyAuthor
Explorer
October 4, 2022

updated drawing

Wayupnorthguy_0-1664919908777.png

 

Wayupnorthguy
WayupnorthguyAuthor
Explorer
October 5, 2022

Perhaps I need to establish a VIP on the private network to act as a type of port proxy for the SMTP traffic???

aionescu
Staff
aionescu
Staff
October 5, 2022

Hi @Wayupnorthguy , to clarify - the NMS server is not able to reach smtp.gmail.com.

How does the policy that allows the traffic looks like?

 

As for the traffic capture, please run the following commands:

 

putty 1
Stop the traffic and clear the session:

diagnose sys session filter src x.x.x.x where x.x.x.x is the source of the traffic
diagnose sys session filter dst y.y.y.ywhere y.y.y.y is the destination of the traffic
diagnose sys session clear

 

confirm that there is no session with

diagnose sys session list

 

putty 2
diagnose debug flow filter addr x.x.x.x where x.x.x.x is the source of the traffic
diagnose debug flow trace start 100
diagnose debug enable

 

Start the traffic and we should see how a new session is created:

 

putty 1
diagnose sys session list

 

Wayupnorthguy
WayupnorthguyAuthor
Explorer
October 5, 2022

Thanks. 
It's apparent that there is no route from the NMS to the public WAN interface.  This seems to make sense because we only created a point to point private network. 
I see traffic between my client and the NMS however I don't see any Telnet sessions to :25. 
Is a Virtual IP the best way to solve this and enhance security?  I'm assuming the VIP will also need policy to allow access to the public WAN interface.
Also note that the NMS and all related clients on that side are statically assigned with a default gateway in the private subnet. 

Terms & ConditionsAccessibility statement