Access / routing from Wan1 to Wan2

[mapapo]

Hi, me again, A second interesting problem.We have to external Connections over different ISPs. Our Webserver uses WAN1 for incoming traffic. Our Users use WAN2 for Web-Surfing. Everything works fine but If users want to reach our Webserver it doesnt work, It seems that the " Internal Routing" for the outgoing connection on WAN2 to WAN1 somehow fails. Is there a policy I have to add for that case, or a route ? I am using MR06 Many thanks

[ejhardin]

What??? Ok first please agree with my statement that it is a security risk to exit a firewall to access internal resoucres. If he has a policy that forces port 80 traffic through wan2 and the web server is accessed with wan1 then how is it not leaving the public interface?

For the web-server the internal users will look like internet-users

That' s becuase they are internet users. Split DNS is very easy...if he is using AD it would take 3 seconds to resolve this issue. How is it another point of failure?

[rwpatterson]

The traffic ' leaves' the internal interface destined for the public IP address. The firewall sees that it has this IP address, and sends the traffic back ' in' via the second policy. Never leaves the box.

[romanr]

ORIGINAL: ejhardin What??? Ok first please agree with my statement that it is a security risk to exit a firewall to access internal resoucres.

I totally agree to that statement! But no-one here is talking about a situation where internal traffic would leave the firewall! None of the packets would ever be seen on a wan1 or wan2 port! Split DNS with AD is pretty easy in some situations... But not everyone has AD in place for all of that... I' ve seen situations where it made the situation even more complex... mostly because of admins have just forgot to manage 2 dns zones then! ... which could easily lead to situations where MXs are not in place so on... cheers.roman

[rwpatterson]

One firewall statement is far easier than installing AD, updating DNS...... How much traffic is there going to be anyway? A couple dozen hits a day? Not a very large load...

[ejhardin]

Technically that is still a loopback because you start out on interface A to travel to interface B to arrive back at interface A. Why would you want to go through the trouble of configuring your firewall to route the traffic and put an extra load on the firewall when the user could simply just access the web server directly. If it is on the same network the firewall should not do any routing.

[ejhardin]

I' m sorry guys but I do not agree... Your configuration is a loopback scenario which is less secure. My configuration the firewall would not be involved. Spend the time to do it right

[UkWizard]

I' m sorry guys but I do not agree... Your configuration is a loopback scenario which is less secure. My configuration the firewall would not be involved. Spend the time to do it right

I agree with rwpatterson with this one, most of what you are saying isnt quite correct. There is no ' loopback scenario' as such, its just all internal routing, which is what the firewalls job is. Even in your suggestions routing would still have to take place. I do agree its easy to resolve to the ' real' dmz address, using DNS, and I do sometimes do this for customers. But its easier to not create extra work for yourself, epecially in the long term, when servers, ISPs change. Also, doing it your way would not allow the benefits of load-balancing and port-forwarding etc, which the VIP provides... In terms of extra load on the firewall by using the VIP, in my opinion, its negligable.

[ejhardin]

Is the web server and the internal users on the same switch? How would an ISP change make it extra work? Internal users are using private IP address not public. If you change ISP' s the internal users will not even know or care. His issue states nothing about a DMZ. Maybe we are on different pages... My understanding is that the web server and the internal users are using private ip address and are on the same switch and the switch is connected to the firewall. All outbound access goes through wan2 and the web server is published via a public IP assigned from wan1 (VIP policy), correct?

[mapapo]

Many Thanks for all your Input, I have now an interesting new effect. My Fortinet works with AD-Authentification. For Outgoing Connections from my PC this works well, I tested this really deep (Login as someone, not allowed to go outside via SMTP or POP3 or IMAP, login as me, everythink works). But the " Loopback-Connection" to Wan1 Doesnt work with this policy. When I make the policy without authentification but just my IP-Address it works. What works well for outgoing connections does not work for " Loopback-Connections" though when I understand the Active-Directory-Connector rights it checks just " Whos the guy with that IP" ? Strange

[mapapo]

No, The Users are on the Internal Interface. The Webserver is in the DMZ. Before adding a second ISP I only used WAN1. When the Users connected to the Webpage The connected to the public IP and the fortinet knew what to do. Now I have a second ISP on WAN2, the users are via a route forced to surf over wan2. When I work with static IPs and have a policy like From Internal to Wan2 allow http everything works. When I use a policy with AD Authentification reaching " really outside" Webservers like www.fortinet.com works, so I thinks somehow my policy must work (also when I logon with a user not allowed to surf his attempt to surf is blocked) But I can no longer reach the " internal" Webserver over its public IP-Address. This is really strange.