Bind on application is over-ridden by netbalancer?

Home Page Forums Network Management Firewall, Traffic Shaping and Net Balancer Bind on application is over-ridden by netbalancer?

This topic contains 5 replies, has 0 voices, and was last updated by  houkouonchi 8 years, 10 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #42559

    houkouonchi
    Member

    It looks like the netbalancer seems to over-ride what interface/IP the packets are showing as their source even when it is specifically set with the ‘bind’ option.

    Here is an example:


    admin@zeroshell: 02:33 PM :~# wget --bind-address=173.58.136.98 -q -O - http://208.97.143.21/ip.php
    173.58.136.98
    admin@zeroshell: 02:34 PM :~# wget --bind-address=96.229.135.204 -q -O - http://208.97.143.21/ip.php
    173.58.136.98
    admin@zeroshell: 02:34 PM :~# wget --bind-address=173.58.136.98 -q -O - http://208.97.143.21/ip.php
    96.229.135.204

    For example doing the same on a ClearOS box does not ever show an issue like this.

    Also according to netstat the process is binding to the correct IP, For example I see:


    admin@zeroshell: 02:38 PM :~# netstat -n -p | grep -i wget
    tcp 0 0 173.58.136.98:41041 208.97.143.21:80 ESTABLISHED 17666/wget

    Any idea what could cause this? I want to be able to force a specific application to use a specific IP/interface based on what the application binds to. This works correctly on a multiwan box I have at work which doesn’t really balance through the interfaces but just sets up the multiple interfaces/geateways via iproute2 (one being the default) IE:


    ip route del table line1
    ip route add table line1 to default via $gw0 dev bond0
    ip route del table line2
    ip route add table line2 to default via $gw1 dev eth1
    ip route del table line3
    ip route add table line3 to default via $gw2 dev bond0
    ip route del table line4
    ip route add table line4 to default via $gw3 dev bond0
    ip route del table line5
    ip route add table line5 to default via $gw4 dev eth0
    ip rule del from $ip0 table line1
    ip rule del from $ip1 table line2
    ip rule del from $ip2 table line3
    ip rule del from $ip3 table line4
    ip rule del from $ip4 table line5
    ip rule add from $ip0 table line1
    ip rule add from $ip1 table line2
    ip rule add from $ip2 table line3
    ip rule add from $ip3 table line4
    ip rule add from $ip4 table line5
    ip route add default via $gw0 dev bond0
    #50849

    ppalias
    Member

    As you can see here the LOCAL PROCESS is before the routing decission, MANGLE OUTPUT, MANGLE POSTROUTING and NAT POSTROUTING, so the content of the packet can change easily before the packet starts its journey on the wires.
    In order to achieve what you want, you can do it the same way you do it in your other linux box. Set mark of 0x66 (this is an example, see what are the marks available in “ip rule ls”) to the application you want to send over a specific interface and the netbalancer will do the rest.

    #50850

    houkouonchi
    Member

    Ok, so if I am understanding you correctly from this output (my two connections 67/65):

    admin@zeroshell: 06:01 PM :~# ip rule ls
    0: from all lookup local
    32764: from all fwmark 0x67 lookup 103
    32765: from all fwmark 0x65 lookup 101
    32766: from all lookup main
    32767: from all lookup default
    admin@zeroshell: 06:01 PM :~#

    I can just add rules like I have on my box for 101/103?

    IE:

    ip rule add from $LINE1_IP table 101
    ip rule add from $LINE2_IP table 103

    and I should be able to reliably bind a specific program to a specific IP?

    If so I assume with dynamic IPs I would need to write a script that grabbed the IP of the interface. Where would the best place to put this script in Startup/Cron?

    #50851

    ppalias
    Member

    I don’t know if that will work. Maybe you should try the iptables to mark the packet, depending on the source IP.

    #50852

    houkouonchi
    Member

    @ppalias wrote:

    I don’t know if that will work. Maybe you should try the iptables to mark the packet, depending on the source IP.

    Ah, that might work! I do notice that netstat will even show the correct IP so I am hoping that will indeed work. I will just need to have it figure out the IPS when it running since my connections aren’t static. Are there variables already assigned to the IPs or will I have to manually edit my stratup/cron options for firewall initialization and manually write a script that adds the correct iptable commands? I am guessing its in the NAT table so I will likely have to do that anyway eh? I already am doing that for my work’s VPN is accessible from machines behind the NAT. I had to setup a custom VPN connection as my work uses tun instead of tap and I can’t change that.

    Thanks for the help.

    #50853

    houkouonchi
    Member

    And that did work, just how I wanted:


    admin@zeroshell: 03:37 AM :~# iptables -t mangle -A NetBalancer -p all -s 96.229.135.204 -j MARK --set-mark 101
    admin@zeroshell: 03:39 AM :~# iptables -t mangle -A NetBalancer -p all -s 173.58.136.98 -j MARK --set-mark 103

    then running in a loop each time when running wget with –bind-address=$ip it showed the expected IP as the result:


    admin@zeroshell: 03:42 AM :~# for i in `seq 1 20`; do echo 173.58.136.98; wget --bind-address=173.58.136.98 -O - -q http://208.97.143.21/ip.php; echo; echo 96.229.135.204; wget --bind-address=96.229.135.204 -O - -q http://208.97.143.21/ip.php; echo; sleep .5s; done
    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204

    173.58.136.98
    173.58.136.98

    96.229.135.204
    96.229.135.204
    #50854

    houkouonchi
    Member

    This is what I added to ‘Firewall Chain in:

    Startup/Cron:


    ip1check=`/sbin/ifconfig ETH01 | /bin/grep -c inet addr`
    ip2check=`/sbin/ifconfig ETH02 | /bin/grep -c inet addr`

    if [ $ip1check -gt 0 ]
    then
    ip=`/sbin/ifconfig ETH01 | /bin/grep inet | /usr/bin/cut -d':' -f2 | /usr/bin/cut -d' ' -f1`
    /usr/local/sbin/iptables -t mangle -D NetBalancer -p all -s $ip -j MARK --set-mark 101 2> /dev/null
    /usr/local/sbin/iptables -t mangle -A NetBalancer -p all -s $ip -j MARK --set-mark 101
    fi

    if [ $ip2check -gt 0 ]
    then
    ip=`/sbin/ifconfig ETH02 | /bin/grep inet | /usr/bin/cut -d':' -f2 | /usr/bin/cut -d' ' -f1`
    /usr/local/sbin/iptables -t mangle -D NetBalancer -p all -s $ip -j MARK --set-mark 103 2> /dev/null
    /usr/local/sbin/iptables -t mangle -A NetBalancer -p all -s $ip -j MARK --set-mark 103
    fi

    I figured the above code should help it work even if my IP address changes. Also I have it delete the rule first so other firewall changes dont make a bunch of duplicate rules in the NetBalancer chain.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.