July 10, 2009 at 10:07 am #41779
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 188.8.131.52 22 I get the ssh prompt without problem.
If I do a telnet 184.108.40.2066 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
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 manglingJuly 12, 2009 at 8:48 am #48397
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.July 13, 2009 at 10:18 am #48398
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.
ThanksJuly 6, 2010 at 9:45 am #48399
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.July 7, 2010 at 12:42 pm #48400
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?July 7, 2010 at 1:36 pm #48401
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?
You must be logged in to reply to this topic.