2 Replies Latest reply on Jul 26, 2011 10:41 AM by mcisar

    SG565 Routing issue

      Have an SG-565 configured with two WAN connections (lets call them Fibre and ADSL).  Recently did some equipment shuffling and moved a couple of DNS servers that had been sitting directly out on the Fibre connection on the internet to the inside of the McAfee, set up the NAT and port forwarding and all appeared to be fine, can access either one of the servers on the inside from either a Fibre IP or an ADSL IP from the outside.


      Got a couple of calls from a handful of clients that could no longer access the DNS servers and after pulling out every last one of my hairs have (I think) figured out the cause...  need help figuring out if there's a solution now.


      The ADSL side of the SG565 has 4 consecutive static IPs from a /26 network, the Fibre side has 4 from a /25 network.  The IP's that the clients were using to try to access the DNS were on the Fibre side (and work fine from outside tested from my home cable connection).  However as it turns out, the clients who are having difficulties happen to be ADSL clients, and they just happen to have IP's that are out of the same /26 subnet as the 4 ADSL IP's i have on the Snapgear.


      My thoughts are that despite the fact that the traffic is coming in on the Fibre IP, the snapgear is seeing that the client's IP address is in the same subnet as our ADSL IP's and getting confused and trying to send the traffic out the ADSL route instead of sending it back out the Fibre IP the way it came in.   I'm waiting to hear back from a customer to see if they can see the DNS server if they try to talk to it on one of the ADSL side IPs, though I'm guessing that will work for them just fine since the traffic will go back out the ADSL.


      For any other clients not on that same ADSL subnet, the traffic seems to happily go back out the same way it came in whether that is on the Fibre or ADSL.


      Any suggestions on how I might resolve or further troubleshoot this issue?



      >>>>> Mike <<<<<

        • 1. Re: SG565 Routing issue

          Mike -


          I'm guessing that routing is an issue, but I'm also anticipating that your SG565's default gateway is pointing to the router connected to the Fibre circuit.


          Event though you have two configured WAN interfaces you can only have one default route/gateway (unless the second WAN interface is being used for redundancy - which it clearly isn't in your case). So even though you have identify traffic arriving via either ADSL or Fibre connections, as far as the firewall is concerned, the source IP address is on the "outside" and it will use it's default gateway to send the return traffic - this results in the traffic arriving to one WAN interface, but the responses are being sent (by virute of the default gateway) out of the other.


          It is possible, however, that as the affected clients have IP addresses from the same /26 subnet as used by the SnapGear, that it's being too clever for it's own good and is then routing the responses out through the wrong interface.


          It's not an area which I've used extensively, but have you tried creating a policy route (Network Setup -> Routes -> Policy Routes) to force all DNS traffic arriving on the "Fibre" interface to be routed back through the gateway IP address served by that connection?


          All things being equal, even though the source IP address will be seen by the SnapGear as being part of the same subnet as it's "ADSL" interface, the fact that the DNS traffic has arrived via the "Fibre" interface will force the responses to be send back out via the Fibre router.


          Hope that helps.



          • 2. Re: SG565 Routing issue

            Thanks for your input Phil, to this point accessing either the ADSL or Fibre IPs from anywhere in the world, was working just peachy... except "foreign" IP's on that same /26 ADSL subnet.  So i think it's definately fair to say that the SG is trying to be smart... and to be truthful in a flat-IP world that might even be a valid "smartness" since that ultimately would be the shortest route back to the source.  However with the ADSL network here just because you are on the same subnet doesn't mean that you are on a completely different router in a different part of the city and I suspect that it's somewhere within the internal loops and hoops of the ADSL network that the plan gets foiled.


            I've thrown a couple of policy based routes in the config this morning and will see what the clients have to say, it definately sounds like it might force the issue.  Will keep you posted.



            >>>>> Mike <<<<<