Dual WAN IIS Setup
All Replies
-
if I am doing SMTP — would I change 80 to 25? or have a group of both?
so in your case 25
Is what your wanting to do that when WAN1 fail for WAN2 NAT to port 25 to have that service go out WAN2?
The idea is the first rule takes the source port 25 to go out WAN1 that when ping fails the next rule takes the source port 25 to WAN2 but this mean NAT from WAN2 to port 25 will fail until WAN1 fails
But maybe if the server for port 25 has two IP's 192.168.0.25 and 192.168.0.225 that you NAT port 25 on WAN1 to 192.168.0.25 and NAT port 25 on WAN2 to 192.168.0.225 with the routing rule by source IP might work? I would think when traffic comes in to a given IP the system uses the correct IP back out?
0 -
Still doesn't work. Interestingly enough, I can trace the response from the Exchange Server and it is clearly Internal IP to Remote IP. The Zyxel properly translates this to the Public IP (the correct one) but then sends it to the wrong WAN interface. I added a Policy Rule that says for any source address of the Public IP, send it out WAN2… but that rule must get processed BEFORE the Address Translation…. What I need to do I guess is tell the Xyxel that any address AFTER Address Translation that matches the WAN2 Public IP needs to go out WAN2…
0 -
Did a test setup here with Zywall 110 by Virtual Server NAT and how I said with routing rules it worked out fine
0 -
Peter — first off, thanks for the assist.
Failover when WAN1 fails works like a charm. But I want the two addresses (one from each ISP's bank of 5 Static/Public IPs) to both be live as I run Active/Active. So if an SMTP SYN comes in on WAN1 to IP 63.x.x.x:25 it should go to the internal 192.168.x.x SMTP Server. And if an SMTP SYN comes in on WAN2 to IP 104.x.x.x:25 it should also to the internal 192.168.x.x SMTP Server. That all works just fine.
Outbound is problematic - when the SMTP Server responds back with the SYN,Ack it goes fine to the Xyzel. All good at this point. And the Zyxel takes and SNAT knows where it came from and converts the outgoing packet Source to be the proper Public IP that is came is as (104.x.x.x or 63.x.x.x)… That much works, again, just like it is supposed to.
But then is seems to forget which WAN it came in on. And sends them all to WAN1. If it came in on WAN1 to 63.x.x.x, it goes out WAN1 as 63.x.x.x. and it all connects and works. However, if it came in on WAN2 to 104.x.x.x, it goes back out on WAN1 as 104.x.x.x which ends up going nowhere.
In essence, the Source address translation is properly 'sticky' but the WAN port is not. If it remembered the inbound WAN port, it will all work perfectly…
Thanks again for the help….
0 -
Oh, btw, I use 1:1 NAT for the server — should I be using Many 1:1 NAT or Virtual Server? Would that help?
0 -
Yes…I see the problem now it does what you say that when WAN1 ARP fails it followers the NAT rule order yes when both WAN's are on line it follows what WAN it come in on to go out on…it like it knows a WAN has failed but then follows the NAT rule order causing the WAN that is online to come in but try to go out the failed WAN…
and this problem must be on a lot of models not sure about H one
let me try some stuff to work around it…
0 -
So their is a problem that needs looking in too
But a fix is what I said for port 25 for the server to have two IP's 192.168.0.25 and 192.168.0.225 that you NAT port 25 on WAN1 to 192.168.0.25 and NAT port 25 on WAN2 to 192.168.0.225 this way it will work when WAN1 fails ARP
0 -
i think you are right… have to dual home the server so that it all stays straight…. Let me try that..
0
Categories
- All Categories
- 415 Beta Program
- 2.4K Nebula
- 148 Nebula Ideas
- 96 Nebula Status and Incidents
- 5.7K Security
- 262 USG FLEX H Series
- 271 Security Ideas
- 1.4K Switch
- 74 Switch Ideas
- 1.1K Wireless
- 40 Wireless Ideas
- 6.4K Consumer Product
- 249 Service & License
- 387 News and Release
- 84 Security Advisories
- 29 Education Center
- 10 [Campaign] Zyxel Network Detective
- 3.5K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 85 About Community
- 73 Security Highlight