December 23, 2009 at 4:20 am #42115
I’m running dual DSLs (PPP0 & PPP1, weighted routing) into my Zeroshell box and I use Virtual Hosts to forward ssh (port 22), and TightVNC (port 5900) to a server.
I can ssh into the server through BOTH DSL connections and it works (VERY SLOW).
I can not VNC in through either DSL line but, I CAN VNC from inside the LAN just fine.
The firewalls settings are default.
Any ideas???December 23, 2009 at 4:32 am #49306
I couldn’t post the above message because every time I hit the SUBMIT button, I would go back to the login screen.
So, I disabled one of the DSLs and that allowed me to post to this forum… I then tried SSH again and the speed was normal so apparently the weighted routing is messing up cookie’d websites and sending half of the SSH data of into never-neverland.
TightVNC STILL didn’t work.
Anyone have an idea what I need to look at to solve this data-splitting problem for cookie’d websites?December 23, 2009 at 9:16 am #49307
Unfortunately both are well known problems of ZS. For the cookie sites you are advised to apply a static route in order to send traffic over one connection only.
For the incoming connections I have created a balancing rule in Netbalancer so that SSH connections go through ppp0 and VNC through ppp1.
We all hope those problems will be soon repaired.December 24, 2009 at 2:04 pm #49308
My problem is slightly different. I’m using MLDonkey and via Virtual servers/Net balancing it’s working fairly well.
The only thing to improve is that there’s no way to know which address will ZeroShell return when MLDonkey makes a port test. So, it’s fairly common for MLDonkey to test the wrong address and get lowID.
The connections are dynamic IP, so there is no way to know the addresses beforehand.
I believe it is a different problem from that of the previous poster, but I’m not sure.
Thank you in advance.December 24, 2009 at 11:16 pm #49309
Create a Virtual Server entry, one for each WAN connection 😉December 25, 2009 at 3:14 pm #49310
Thank you for your reply, I wasn’t expecting one so fast in Christmas 🙂
Yes, I have a virtual server for each connection, and I route all P2P via 3g modem (ppp1). That is working fine.
What leaves me at a loss is that even if I put a balancing rule to send all the traffic (no protocol filter, no port filter, only “from” address filter) that comes from the machine running MLDonkey via ppp1, MLDonkey keeps using the wrong IP address (the one given by the ISP to ppp0, adsl connection) to make a port test.
This happens roughly 60% of the time (the weight of the adsl gateway).
Anyway, I have come to a solution of sorts setting MLDonkey to discard connections with lowID. Crude but effective.
I would have liked to know what’s going on, though. 😕
But it’s a very minor point. ZeroShell rules! 😀
Merry Christmas to you, ppalias!December 26, 2009 at 11:49 am #49311
That is weird, I used this solution for my same problems. As far as I know if you create a netbalancing rule it overrides even the fact that the link you are sending it through is on a backup state, instead of active.
Merry Christmas too!January 3, 2010 at 2:12 pm #49312
It seems that I have the same problem.
I cannot let Virtual Server works with Net Balancer.
When I enabled the 2nd ppp and Net Balancer, all Virtual Server settings seem to be ignored.
How to add balancing fule for incoming connections?January 3, 2010 at 3:04 pm #49313
Incoming connections cannot be load-balanced, they will come on a WAN interface. What you MUST do is make sure the reply goes out of the SAME WAN interface, otherwise your peer will drop it. Although this should work by itself using the NAT table, you have to do it manually.
For example if you have a web server 192.168.1.2:80 and a mail server 192.168.1.3:25 with ppp0 and ppp1, then you have to make a netbalancer rule for 192.168.1.2 s_port 80 to go through ppp0 and create a virtual server on ppp0 for d_port 80 requests. Same for mail on the other WAN, create a netbalancer rule for 192.168.1.3 s_port 25 to go through ppp1 and a virtual server on ppp1 for port 25.
You must be logged in to reply to this topic.