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

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
  • I haven't used that option for the nat masq usually use SNAT, but both should work. The only exception is for the proxy traffic, are you running the http proxy?
  • Why would an http proxy affect anything? Yes, I'm running an http proxy.

    /slaps self in forhead

    That makes sense for browsing but the machine that is supposed to be snatted is doing voip connections to our provider and still showing up as our main internet addy. In this case http proxy shouldn't necessarily be the problem.
  • I even set just the voip protocols

    SomeComputer -> rtp -> snat -> InternetSecondary
    SomeComputer -> sip -> snat -> InternetSecondary

    Nothing works.

    Let me re-phrase that, the connection as shown at callcentric is InternetMain. I'm assuming this means the initial conversation came in from that IP addy.
  • Is there a linux non-http method of finding out my true exposed address? Everything I've seen uses http.
Reply Children
  • I'm giving up on this for the night, but I'm simply furious. Why doesn't this work? Even the knowledge base articles for versions before 7.5 say to use SNAT for this. Why does both masq and snat fail to set the source IP addy to the one I want?
  • Is there a linux non-http method of finding out my true exposed address? Everything I've seen uses http.

     
    on the command line:
    tcpdump -ni pppX host DESTIP
     
    where pppX = netowrk device of your WAN conenction (i.e. ppp0, or eth1, eth2 or whatever you use)
    DESTIP = IP adrress of the external host to which your internal client send packets.
     
    You then can see whether the ASG sends these packets out with source Ip InternetMain or InternetSecondary
     
     
     
    I'm giving up on this for the night, but I'm simply furious. Why doesn't this work? Even the knowledge base articles for versions before 7.5 say to use SNAT for this. Why does both masq and snat fail to set the source IP addy to the one I want?

     
    Please post output of 
    iptables -L -nv -t nat
     
    here
  • Chain PREROUTING (policy ACCEPT 557K packets, 48M bytes)
     pkts bytes target     prot opt in     out     source               destination
     600K   51M AUTO_PRE   all  --  *      *       0.0.0.0/0            0.0.0.0/0
     580K   50M USR_PRE    all  --  *      *       0.0.0.0/0            0.0.0.0/0
     557K   48M LOAD_BALANCING  all  --  *      *       0.0.0.0/0            0.0.0.0/0

    Chain POSTROUTING (policy ACCEPT 362K packets, 27M bytes)
     pkts bytes target     prot opt in     out     source               destination
     566K   46M AUTO_POST  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     566K   46M USR_POST   all  --  *      *       0.0.0.0/0            0.0.0.0/0

    Chain OUTPUT (policy ACCEPT 324K packets, 23M bytes)
     pkts bytes target     prot opt in     out     source               destination
     324K   23M AUTO_OUTPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     324K   23M USR_OUTPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0

    Chain AUTO_OUTPUT (1 references)
     pkts bytes target     prot opt in     out     source               destination

    Chain AUTO_POST (1 references)
     pkts bytes target     prot opt in     out     source               destination

    Chain AUTO_PRE (1 references)
     pkts bytes target     prot opt in     out     source               destination
     2690  129K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1024:65535 dpt:4444 ADDRTYPE match dst-type LOCAL
        0     0 REDIRECT   tcp  --  *      *       10.2.1.0/24          0.0.0.0/0           tcp spts:1:65535 dpt:80 ADDRTYPE match dst-type !LOCAL redir ports 8080
    15132  771K REDIRECT   tcp  --  *      *       10.2.2.0/24          0.0.0.0/0           tcp spts:1:65535 dpt:80 ADDRTYPE match dst-type !LOCAL redir ports 8080
        0     0 RETURN     tcp  --  *      *       10.2.1.0/24          0.0.0.0/0           tcp spts:1:65535 dpt:443 ADDRTYPE match dst-type !LOCAL
    23837 1183K RETURN     tcp  --  *      *       10.2.2.0/24          0.0.0.0/0           tcp spts:1:65535 dpt:443 ADDRTYPE match dst-type !LOCAL
        0     0 REDIRECT   tcp  --  *      *       10.2.2.0/24          0.0.0.0/0           tcp spts:1:65535 dpt:110 redir ports 8110
        0     0 REDIRECT   tcp  --  *      *       10.2.1.0/24          0.0.0.0/0           tcp spts:1:65535 dpt:21 redir ports 2121
      127  7548 REDIRECT   tcp  --  *      *       10.2.2.0/24          0.0.0.0/0           tcp spts:1:65535 dpt:21 redir ports 2121

    Chain LOAD_BALANCING (1 references)
     pkts bytes target     prot opt in     out     source               destination

    Chain USR_OUTPUT (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            66.213.240.156      tcp spts:1:65535 dpt:21 to:10.2.1.80
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            66.213.240.155      tcp spts:1:65535 dpt:80 to:10.2.1.80
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            66.213.240.154      tcp spts:1:65535 dpt:80 to:10.2.2.12
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            66.213.240.154      tcp spts:1:65535 dpt:110 to:10.2.2.11
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            173.11.22.169       tcp spts:1:65535 dpt:80 to:10.2.2.12
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            173.11.22.170       tcp spts:1:65535 dpt:80 to:10.2.1.80
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            173.11.22.171       tcp spts:1:65535 dpt:21 to:10.2.1.80
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            173.11.22.169       tcp spts:1:65535 dpt:110 to:10.2.2.11
        0     0 DNAT       udp  --  *      *       0.0.0.0/0            173.11.22.172       udp spts:1:65535 dpts:10000:20000 to:10.2.2.65
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            173.11.22.172       tcp spts:1:65535 dpt:5060 to:10.2.2.65
        0     0 DNAT       udp  --  *      *       0.0.0.0/0            173.11.22.172       udp spts:1:65535 dpt:5060 to:10.2.2.65
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            173.11.22.172       tcp spts:1:65535 dpt:6600 to:10.2.2.65
        0     0 DNAT       udp  --  *      *       0.0.0.0/0            173.11.22.172       udp spts:1:65535 dpt:6600 to:10.2.2.65

    Chain USR_POST (1 references)
     pkts bytes target     prot opt in     out     source               destination
     2359 1166K SNAT       all  --  *      eth3    10.2.2.65            0.0.0.0/0           to:173.11.22.172
    38065 2695K MASQUERADE  all  --  *      eth3    10.2.2.0/24          0.0.0.0/0
     1000 1025K MASQUERADE  all  --  *      eth3    10.2.1.0/24          0.0.0.0/0
     6612  502K MASQUERADE  all  --  *      eth3    10.242.3.0/24        0.0.0.0/0

    Chain USR_PRE (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            66.213.240.156      tcp spts:1:65535 dpt:21 to:10.2.1.80
        2   108 DNAT       tcp  --  *      *       0.0.0.0/0            66.213.240.155      tcp spts:1:65535 dpt:80 to:10.2.1.80
        1    48 DNAT       tcp  --  *      *       0.0.0.0/0            66.213.240.154      tcp spts:1:65535 dpt:80 to:10.2.2.12
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            66.213.240.154      tcp spts:1:65535 dpt:110 to:10.2.2.11
      794 41132 DNAT       tcp  --  *      *       0.0.0.0/0            173.11.22.169       tcp spts:1:65535 dpt:80 to:10.2.2.12
     2216  119K DNAT       tcp  --  *      *       0.0.0.0/0            173.11.22.170       tcp spts:1:65535 dpt:80 to:10.2.1.80
     4171  231K DNAT       tcp  --  *      *       0.0.0.0/0            173.11.22.171       tcp spts:1:65535 dpt:21 to:10.2.1.80
      263 15780 DNAT       tcp  --  *      *       0.0.0.0/0            173.11.22.169       tcp spts:1:65535 dpt:110 to:10.2.2.11
        2   205 DNAT       udp  --  *      *       0.0.0.0/0            173.11.22.172       udp spts:1:65535 dpts:10000:20000 to:10.2.2.65
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            173.11.22.172       tcp spts:1:65535 dpt:5060 to:10.2.2.65
      684  565K DNAT       udp  --  *      *       0.0.0.0/0            173.11.22.172       udp spts:1:65535 dpt:5060 to:10.2.2.65
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            173.11.22.172       tcp spts:1:65535 dpt:6600 to:10.2.2.65
        0     0 DNAT       udp  --  *      *       0.0.0.0/0            173.11.22.172       udp spts:1:65535 dpt:6600 to:10.2.2.65
    firewall:/home/login #
  • 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.