Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 2 subscribers
  • Views 3072 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

I'm not sure why this masq doesn't work

predatorsw
I have public IP addresses InternetMain=xx.xx.xx.111 and InternetSecondary=xx.xx.xx.112 both assigned to one of my external ports, with InternetMain being the main and InternetSecondary the additional interface. I setup the main internal network masq to go to InternetMain. This all works as expected.

I now want to have a SingleComputer show up on the internet as InternetSecondary and not InternetMain.

I setup the masq for SingleComputer -> Interface "InternetMain" with Use Address "InternetSecondary" and push it to the top.

I then jump on that computer, go to "show my IP" and it comes up as InternetMain and not InternetSecondary. What am I doing wrong?


This thread was automatically locked due to age.
  • 0 in reply to predatorsw
    That was using the masq approach, which apparently maps to snat when all is said and done.

    With this callcentric still states I'm coming in from 173.11.22.169.

    So let me restate my problem just to make sure I didn't filter too much out:

    "When my trixbox connects to callcentric, callcentric reports our IP address as .169 and not the address I am MASQING the trixbox to which is .172"

    When we initially setup the trixbox I used the main IP address but this is proving to be a problem. The easiest solution is to move the voip traffic. I figured it'd be a snap but this is most certainly not proving to be the case.
  • 0
    Please show a pic of your SNAT.
  • 0 in reply to BAlfson
    This setup is through the new masq stuff, but I can do it with snat if you want. I meant and edited in my last statement "masqiing" instead of "snatting." The masq is simply:

    trixbox1 -> InternetMainCC/InternetVOIPCC
  • 0 in reply to predatorsw
    So the rule in question is this one:

    2359 1166K SNAT       all  --  *      eth3    10.2.2.65            0.0.0.0/0           to:173.11.22.172

    I do not see any reason why this rule shouldn´t work as expected, if 
    - your client is really 10.2.2.65
    - the conenctions from client to server are not proxied on the ASG

    If you say "callcentric reports our IP address as .169 and not the address I am MASQING the trixbox to which is .172"

    Could it be that callcentrix is reporting the source IP in a different way than you expect?

    Some providers use a http connect to discover the source ip of a client, even if the main connection will be something different (like VoIP in your case).

    DynDNS is doing this, for example: the "client IP" which is reported by DynDNS is the IP from which a client conencts via HTTP to the DynDNS server. Of course, if the client uses a proxy for HTTP, but goes out into the internet with a different IP (not proxified), DynDNS will report something wrong.

    Again, my recommendation: use tcpdump to clarify wich packets are sent out by the ASG - you will quickly see wether it is source IP .169 or .177 - and then probably the problem "vanishes".