› Forums › Network Management › Signal a BUG › 2.0.RC3 NET BALANCER – 1:1 Nat Virtual Servers not managable
- This topic is empty.
-
AuthorPosts
-
September 20, 2013 at 1:28 pm #43734
miketheknife
MemberHi there,
yesterday I upgraded my Soekris 5501 to a Gigabit capable Soekris 6501. My old system was runnung on ZS Release 1.0 Beta14.
I decided to upgrade to Release 2.0.RC3. I am using Zeroshell for many years in different situations. Its a very
good project, keep on moving!My Setup:
WAN Link 1 ETH00: CABLE 100Mbps with dynamic public ip adress
WAN Link 2 ETH01: ADSL 5Mbps with static /28 (16 adresses) public ip range
internal ETH02: users (me) 192.168.10.130
internal ETH02: server 192.168.10.209My Goal:(which was working on 1.0 Beta14):
I want to map my internal server with a 1:1 Nat to on of my static public ip addresses.My Configuration:
I made a 1:1 Nat under Setup -> Startup/Cron -> NAT and Virtual Servers scriptiptables -t nat -I PREROUTING 1 -d 132.15.128.4 -i ETH01 -j DNAT –to-destination 192.168.10.209
iptables -t nat -I POSTROUTING 1 -s 192.168.10.209 -o ETH01 -j SNAT –to-source 132.15.128.4—
Then I added the required rule to the Firewall
—
A and at last I setup the Net Balancer and Balancing Rules:
Failover Mode
Gateway Description | IP Address | Interface | Weight | Timeout Coefficient
ADSL | 132.15.128.1 | | 1 | x8
CABLE | 212.116.202.1 | | 99 | x1I want all outgoing connections to use my fast link so i set the weight of the CABLE to 99
Balancing Rules to route all traffic from the server to the ADSL Gateway:
MARK all opt — in * out * 192.168.10.209 -> 0.0.0.0/0 MARK set 0x65 ADSL (132.15.128.1)—
So far so good! and this setup worked perfectly on 1.0 Beta14. On the latest 2.0.RC3 i can see the following effect:
when I connect from the Internet to the defined external public address of my server 132.15.128.4 i check the firewall interface ETH01 with tcpdump
I see packages comming in. On the server 192.168.10.209 i can see the the packages arriving and leaving towards the firewall again but at the
firewall the packages dont leave through the per Balancing Rule defined Gateway, they leave though the Interface that has the highest weight.
In my case its CABLE ETH00 (99).When I iniciate a connection to the Internet from the shell prompt of the server 192.168.10.209 i get routed correctly through the Balancing Rules defined gateway.
Conclusion:
For me it looks like NET BALANCER’s Balancing Rules are ignoring iptables POSTROUTING rules. In such a case the balancer just goes for the weight of the connection instead of looking at the balancing rules first. Maybe some priority changed from Beta14 to 2.0.RC3, the balancer should look at the rules first and if not found go for the weight.Do you have similar experience?
i saw similar threads:
Internal service behind load balancer – ZeroShell 2.0 RC1 -> https://www.zeroshell.org/forum/viewtopic.php?t=3794Bug in Loadbalacing or Virtual Server in 2.0.RC1 -> https://www.zeroshell.org/forum/viewtopic.php?t=3704
Greets Mike
January 3, 2015 at 5:13 pm #52884beppuz
MemberHi miketheknife,
I’m in the same trouble upgrading from 1.b14 to latest 3.2.1.
The configuration that was working in previous release doesn’t work any more now in routing packets as per nat1:1 configuration.I don’t think it is a netbalancer issue: I have the same problem even disabling netbalancing.
In my configuration I have 4 public ip addresses (80.79.49.74, .75, .76, .77) on ETH03.
All 4 are configured nat1:1 to dmz servers, but only the first one (80.79.49.74) works, i.e. packets come back through ETH03. Packet to the others goes back through ETH02 (which is the default route).I’m stuck trying all possible configurations and wondering if you fixed your issue.
December 6, 2016 at 8:46 pm #52885beppuz
MemberAfter having put this task aside for some months, I’m now trying to fix the problem (without success by now).
Here is my setup:
– ETH00 –> LAN
– ETH01 –> DMZ
– ETH02 –> GW1
– ETH03 –> GW2GW1 + GW2 are in netbalancing (failover), where GW1’s weight is 95 and GW2’s weight is 1.
GW2 has 4 IP addresses (x.x.x.74,x.x.x.75,x.x.x.76,x.x.x.77).
My goal is to map different addresses to different services/servers in DMZ.
So I setup portforwarding and postrouting rules in crontab in order to SNAT specific traffic.
I also setup balancing rules to get all trafic coming from DMZ through GW2.This configuration _was_ working in version 1.beta14.
What happens now:
– services mapped to first address (x.x.x.74) are correctly routed through GW2
– services mapped to the other addresses are routed through GW1 (which is also default gateway). Therefore they never get back to the calling party.Port forwarding config:
ETH03 / x.x.x.77 TCP 25 10.0.1.11:25
ETH03 / x.x.x.74 TCP 110,143 10.0.1.11:110,143
ETH03 / x.x.x.74 TCP 80,443 10.0.1.15:80,443
ETH03 / x.x.x.75 TCP 80 10.0.1.12:80
ETH03 / x.x.x.74 TCP 25 10.0.1.11:25
ETH03 / x.x.x.76 TCP 80,443 10.0.1.14:80,443
Postrouting rules:
iptables -t nat -I POSTROUTING 1 -s 10.0.1.14 -o ETH03 -j SNAT --to-source x.x.x.76
iptables -t nat -I POSTROUTING 1 -s 10.0.1.12 -o ETH03 -j SNAT --to-source x.x.x.75
*** No change even if these rules are commented ***
Net balancing rule:
1 * * MARK all opt -- in * out * 10.0.1.0/24 -> 0.0.0.0/0 MARK set 0x66 GW2 (x.x.x.73)
Any help will be greatly appreciated. Thanks!
December 6, 2016 at 10:14 pm #52886DrmCa
ParticipantI vaguely recall upgrading from 1.0 to 2.0, then to 3.0 and to 3.5.
The profile worked.
Perhaps you can try upgrading incrementally?December 8, 2016 at 4:53 pm #52887beppuz
MemberI changed my hardware, so I think it’s not possible to go the gradual upgrade path (because of how the network interfaces are identified).
Thanks anyway
December 9, 2016 at 5:29 pm #52888DrmCa
ParticipantBummer! Then it sounds like your only option is to bring up an old version in a VM and copy the profile values manually.
December 10, 2016 at 7:44 pm #52889beppuz
MemberThat’s what I did: the same configuration (copied over page-by-page) works in every aspect but using the right gateway in network balancing for some traffic (not all – see my post above).
-
AuthorPosts
- You must be logged in to reply to this topic.