Page 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 58
  1. #31
    Untangle Ninja dwasserman's Avatar
    Join Date
    Jun 2008
    Location
    Argentina
    Posts
    4,367

    Default

    ratitude:

    Can you write a sticky post with best practices in an envoirment whit Untangle manage many publics IP? For now i dont have this scenario to obtain print screen whit examples.

  2. #32
    Master Untangler HomeNet's Avatar
    Join Date
    Sep 2007
    Location
    Pennsylvania, USA
    Posts
    193

    Default

    Quote Originally Posted by dwasserman View Post
    ratitude:

    Can you write a sticky post with best practices in an envoirment whit Untangle manage many publics IP? For now i dont have this scenario to obtain print screen whit examples.
    Careful.... When I made these changes, we had some other issues. Obviously, the customer blamed me! When I rolled back the changes, the customer's issues didn't go away. While I could now prove to them I didn't break anything, I also noticed that everything was back to normal again - without all the changes we talked about yesterday! I have to explore and play with this some more...

    I'm not saying Raditude gave me bad info. I'm merely saying don't base the write-up on my network. It's less than ideal...
    Last edited by HomeNet; 03-17-2010 at 09:11 AM.

  3. #33
    Untangle Ninja raditude's Avatar
    Join Date
    Jan 2009
    Location
    Eugene, OR
    Posts
    1,143

    Default

    what are the other issues?

  4. #34
    Master Untangler HomeNet's Avatar
    Join Date
    Sep 2007
    Location
    Pennsylvania, USA
    Posts
    193

    Default

    Quote Originally Posted by raditude View Post
    what are the other issues?
    Funniness with pings/trace-routes through their MPLS...

    I have route statements to route traffic from one location to another across their MPLS. Their Verizon MPLS network went down and I began trying to ping/trace-route stuff on the other end and vice-versa. The trace-routes never got through the UT server that we were working with yesterday. However, as soon as I removed the NAT policies, they got to the next hop and that helped me deduce the issue with the MPLS.

  5. #35
    Untangle Ninja raditude's Avatar
    Join Date
    Jan 2009
    Location
    Eugene, OR
    Posts
    1,143

    Default

    It is hard to say what the issues are then, it sounds like your MPLS is/was an issue.

    One good way to check to see if you have your NAT right is put your policy in place, then go to a site that will check you IP address (dnsstuff.com, or a site like that), when the policy is not in place the server in question should give the default/primary IP address, with the NAT policy in place you should get the appropriate IP address you are looking for, and if your requests are coming in on a different IP than your primary IP, but getting a reply from your primary the service on the other end should deny/drop the request, as it is getting a reply to a request from a different address than was originally contacted. If this was not in place it would allow any address to reply (or send out attempts) for whatever reason, the packet flood by hackers would be a firestorm, and cripple the internet.

  6. #36
    Master Untangler HomeNet's Avatar
    Join Date
    Sep 2007
    Location
    Pennsylvania, USA
    Posts
    193

    Default

    Quote Originally Posted by raditude View Post
    It is hard to say what the issues are then, it sounds like your MPLS is/was an issue.

    One good way to check to see if you have your NAT right is put your policy in place, then go to a site that will check you IP address (dnsstuff.com, or a site like that), when the policy is not in place the server in question should give the default/primary IP address, with the NAT policy in place you should get the appropriate IP address you are looking for, and if your requests are coming in on a different IP than your primary IP, but getting a reply from your primary the service on the other end should deny/drop the request, as it is getting a reply to a request from a different address than was originally contacted. If this was not in place it would allow any address to reply (or send out attempts) for whatever reason, the packet flood by hackers would be a firestorm, and cripple the internet.
    Well, obviously, we figured out it was the MPLS but why everything acted the way it did, I'll never know... Like I said, I'll have to play with this some more.

  7. #37
    Untangle Ninja raditude's Avatar
    Join Date
    Jan 2009
    Location
    Eugene, OR
    Posts
    1,143

    Default

    It could have been caused by the change in NAT we did, because as soon as you changed the NAT, the traffic across any static routes you had on the MPLS would no longer match up, thus you would get some funniness, because stuff would be using cached information.

  8. #38
    Master Untangler HomeNet's Avatar
    Join Date
    Sep 2007
    Location
    Pennsylvania, USA
    Posts
    193

    Default

    Quote Originally Posted by raditude View Post
    It could have been caused by the change in NAT we did, because as soon as you changed the NAT, the traffic across any static routes you had on the MPLS would no longer match up, thus you would get some funniness, because stuff would be using cached information.
    The thing is...none of the routes (screen-shot) were listed in the NAT policies. So, how could they even get caught up in it?

  9. #39
    Untangle Ninja raditude's Avatar
    Join Date
    Jan 2009
    Location
    Eugene, OR
    Posts
    1,143

    Default

    I was speaking more on the MPLS side of it, IF the traffic was going over it, then you made a change, I have seen weird things happen to traffic where the traffic gets lost, goes via a cached route.

  10. #40
    Master Untangler HomeNet's Avatar
    Join Date
    Sep 2007
    Location
    Pennsylvania, USA
    Posts
    193

    Default

    Quote Originally Posted by raditude View Post
    I was speaking more on the MPLS side of it, IF the traffic was going over it, then you made a change, I have seen weird things happen to traffic where the traffic gets lost, goes via a cached route.
    The only traffic that would travel over the MPLS is that which is forced to do so via the route statements.

    The NAT policies were only put in to allow remote access to the servers on the local subnet so that traffic should only be going between the WAN interface & said servers and therefore not over the MPLS line.

Page 4 of 6 FirstFirst ... 23456 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2