[HOWTO] Virtual servers and multiwan port forwarding problem

Home Page Forums Network Management ZeroShell [HOWTO] Virtual servers and multiwan port forwarding problem

This topic contains 4 replies, has 0 voices, and was last updated by  aseques 9 years, 4 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #41779

    aseques
    Member

    I’ve more or less the scenario in the picture (ip addresses have been altereded), the problem is that I can only connect to the Terminal server behind and to the firewall (ports 443 and 22) using the main dsl line.

    If from outside I do a telnet 123.123.123.123 22 I get the ssh prompt without problem.
    If I do a telnet 123.123.123.456 22 there’s no answer.

    It seems that the traffic is going back using the DSL1.
    Is zeroshell capable of returning the traffic to the interface it came from? That would be the cleanest way of doing this if possible.

    The workaround would be to use another port and to create a rule for that, but it’s not very practical.

    Same problem as http://www.zeroshell.net//forum/viewtopic.php?t=1515
    One possible solution: http://www.zeroshell.net/eng/forum/viewtopic.php?t=1283
    Basically changing the MASQUERADE into something different

    Two scenarios:

    Public IP on zeroshell
    Redirecting port with multiwan is trivial if you have the public IP on your zeroshell, either with PPPoE dialing or setting your router to do so.
    On those cases the only thing you have to do is to go to Network -> Router -> Virtual Server and create the port mappings you need.
    NATed IPs on zeroshell
    On the this cases is much more complicated, since it involves changes in the way MASQUERADING is don or packet mangling

    #48397

    ppalias
    Member

    I have the same setup as you. What I do in order to avoid situations like the one you mentioned is to terminate the PPPoE on the ZS. The modem is in bridging mode, so all NAT tables are on ZS and it can send the answer back on the correct interface.
    Otherwise you should somehow mark the incoming packets and make sure the answer will be sent to the same interface it came from with a policy based routing rule.

    #48398

    aseques
    Member

    Ok, that’s a unexpected problem, usually I try to setup the customer router so I can have the public IP address, but with some companies this is not a thing you can do.
    I’ll try the packet mark and see what happens.

    Thanks

    #48399

    Savar
    Member

    That doesn’t worked for me. I have 4 WAN ports directly at the zeroshell and when i tried to do a telnet on the VPN port the answer has had the correct SOURCE IP (the same like i telneted to) but it was send out on another WAN port.

    Maybe this can work but i think my provider dropped this packets because it didn’t come from the ip he gave to me.

    So to be sure that the traffic will go through the correct WAN i have to use this command:

    iptables -t mangle -I PREROUTING 2 -i ppp3 -m state --state NEW -j MARK --set-mark 0x64

    now every new connection coming in from ppp3 will be set to the mark 0x64 which was set (from zeroshell) with the ip tool to:

    root@zeroshell root> ip rule
    ...
    32762: from all fwmark 0x64 lookup 100
    ...

    and when you look to the routing table for the table 100:

    root@zeroshell root> ip route show table 100
    ...
    default via X.Y.Z.200 dev ppp3
    ...

    you see the connection tracked as 0x64 will go through the outgoing interface ppp3 and now i can connect from outside.

    #48400

    RDelpopolo
    Member

    Can you explain me better the thinks to do?
    I’m a newbie and can’t make it to work 🙁

    Can you give me the commands that you run to marlk correctly the packets?

    #48401

    ppalias
    Member

    I remember having the same problem. When I SSHed my server from the internet and used load balancing some packets were sent out of the wrong interface. It was so bad that I was forced to switch to Failover only. After applying Atheling’s patch for load balancing I got a normal behavior. Have you tried it too?

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

You must be logged in to reply to this topic.