Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 2 subscribers
  • Views 3059 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.
Parents
  • 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".
Reply
  • 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".
Children
No Data