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

port forward through vpn tunnel

two office location , link together with vpn tunnel successfully first office have static public ip on fortigate 60B WAN interface. second office is rented office which using internet from lanlord network that we have no control of. fortigate 50B is behind lanlord NAT router second office have private ip on fortigate 50B WAN interface. two office successfully link together with IPsec vpn tunnel. fortigate 60B config as " fortigate dialup vpn server" fortigate 50B config as " fortigate dialup vpn client" it is site-to-site vpn tunnel there is e-mail server in second office, ip:192.168.5.10 connect to lan interface of fortigate 50B. i want mobile user when they travel, their can use webmail of server in second office. so I have to forward port 80 on wan interface of fgt60B to server in second office through vpn tunnel. if server is in first office it will be very easy, but this case server is in second office which can only access through vpn tunnel. subnet of fgt60B is 192.168.10.x / 24 subnet of fgt50B is 192.168.5.x / 24 how to port forwarding through vpn tunnel ?
11 REPLIES 11
Tum
New Contributor

I have config VIP on WAN interface of FGT60B 58.136.222.88 port 80 ---> 192.168.5.10 port 80 and set firewall policy to allow traffic from WAN to VPN interface (route-based vpn) but packet still not reach 192.168.5.10. somehow packet not go from WAN interface to VPN interface. any idea ?
Kess
New Contributor

Hi Tum, First Option: Your IPSec Tunnel should be in Interface-Mode and not in policy mode. Then you' ve to setup the correct routing in your routing table. Second Option: You should setup a Reverse-Proxy (simple linux apache) in your " main" network. The external client computers will connect through it and through it only. There are some advantages (security related) in putting a reverse proxy in a DMZ to connect to internal ressources. The Apache directive could look so: <VirtualHost your_internal_ip_address:443> ServerName webmail.externaldomain.net ServerAdmin webmaster@externaldomain.net ErrorLog logs/443/webmail.error.log TransferLog logs/443/webmail.transfer.log SSLEngine On SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /usr/local/apache2.2/ssl/webmail.crt SSLCertificateKeyFile /usr/local/apache2.2/ssl/webmail.key ProxyRequests Off SSLProxyEngine On SSLProxyVerify none ProxyPreserveHost On CacheDisable * AddDefaultCharset UTF-8 RequestHeader unset accept-encoding ProxyVia On <FilesMatch “\.(cgi|shtml|phtml|php)$”> SSLOptions +StdEnvVars </FilesMatch> <Directory “/usr/local/apache2.2/cgi-bin”> SSLOptions +StdEnvVars </Directory> BrowserMatch “.*MSIE.*” nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 CustomLog logs/443/webmail.custom.log “%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b” RequestHeader set Front-End-Https “On” SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire RewriteEngine on RewriteRule ^/$ /owa/ RewriteRule exchange([^/].*) /exchange/$1 [R,QSA,L] RewriteRule exchweb([^/].*) /exchweb/$1 [R,QSA,L] <Location /exchange> ProxyPass https://aa.bb.cc.dd/exchange/ ProxyPassReverse https://aa.bb.cc.dd/exchange/ SSLRequireSSL </Location> <Location exchweb/> ProxyPass https://aa.bb.cc.dd/exchweb/ ProxyPassReverse https://aa.bb.cc.dd/exchweb/ SSLRequireSSL </Location> <Location public/> ProxyPass https://aa.bb.cc.dd/public/ ProxyPassReverse https://aa.bb.cc.dd/public/ SSLRequireSSL </Location> <Location /owa> ProxyPass https://aa.bb.cc.dd/owa ProxyPassReverse https://aa.bb.cc.dd/owa SSLRequireSSL </Location> <Location /> ProxyPass https://aa.bb.cc.dd/ ProxyPassReverse https://aa.bb.cc.dd/ SSLRequireSSL </Location> </VirtualHost> where: - your_internal_ip_address is the real IP address assigned to your internal apache web server - webmail.externaldomain.net is the URL that your users will type in their Internet Explorer - aa.bb.cc.dd is the internal FQDN to reach your Exchange Server (resolvable by your Reverse Proxy) Then you can just configure a VIP from external to your HTTPS reverse proxy and a FW Policy allowing the Reverse Proxy to contact your Exchange server on port 443. This Apache reverse proxy doesn' t need a lot of ressources in order to serve your clients. You can test it with a simple PC with a little CPU and 512MB RAM. Hope it helps. Bye Kess.
Tum
New Contributor

I set route-based vpn and it working now. but it just not route-based vpn alone that make it work. I use 4.0 MR2 patch4 on both fortigate and it was 1. existance of DMZ1 ip, 2. Full inbound NAT need to translate both source and destination ip in packet 3. policy route that take precedence over static route that was prevent me to make it work at first place. if number 1 and 3 do exist, then my port forwarding will not work. so I try to find a way that all can co-existing and port forwarding still work. 1. how to make static route take precedence over policy route ? 2. how to make internal interface take precedence over DMZ1 interface for tunnel routing ? PS: i even try route-based VPN on first office with policy-based vpn on 2nd office. and port mapping still go through tunnel correctly. but again DMZ1 and policy route must not exist.
Tum
New Contributor

this is normal tracert from office1 to office2 (on computer ip 192.168.100.10) it is path 192.168.100.1---> 192.168.5.254 ---> 192.168.5.10 so if you tracert it back from office2 to office1 (on computer ip 192.168.5.10) you would expected 192.168.5.254 ---> 192.168.100.1 ---> 192.168.100.10 it go back and forward in same route path 192.168.100.10 ---> 192.168.100.1 ---> 192.168.5.254 ---> 192.168.5.10 192.168.100.10 <--- 192.168.100.1 <--- 192.168.5.254 <--- 192.168.5.10 but if DMZ interface ip does exist, fortiOS will use DMZ ip instead of internal interface ip. (in this case, DMZ ip is 192.168.50.1) this broke my routing path as in picture. How to override this behavior ? the picture is tracert back from office2 to office1 and it' s not what you expected.
Tum
New Contributor

as you see in the picture. the existing of DMZ interface ip, does change routing path of VPN tunnel. how to override this behavior ?
rwpatterson
Valued Contributor III

Try placing a higher priority (lower number) on the static route through the tunnel. For more help, let' s have the interface IPs and the policy route setup on the 60B (and perhaps the logic behind why you need them).

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
Tum

I have delete all policy routing. so there is no policy routing in my setting anymore. attach picture is current in-use configuration. you can test network as in picture (DMZ ip must exist) and tracert from FGT50B to FGT100A, you will see about routing path I am talking about. this is tracert on pc:192.168.5.10 to pc:192.168.100.10 (Compare the second hop in picture below) in opposite direction, tracert on pc:192.168.100.10 to pc:192.168.5.10 ( it go out to internal interface, not DMZ interface)
rwpatterson
Valued Contributor III

What do your routes look like (Router > Monitor)?

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
Tum

this is routing table of FGT100A and FGT50B, (no policy route, no user defined static route) FGT50B interface VPN tunnel of FGT100A and FGT50B
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