› Forums › Network Management › ZeroShell › Heinzelmännchen Problem
- This topic is empty.
-
AuthorPosts
-
April 23, 2010 at 10:17 pm #42372
Pit
MemberHello ,
from the lan side of zeroshell i can reach hosts at port 80, 443 and 444 at internet.
If i try to reach a special host at ports 1812, 1813 and 7000 nothing happens.
A tcpdump at special host shows that the connection is made, but at ports 33xyz.
Has someone any idea what heinzelmännchen scrumble my destination ports?
Regards
Pit
April 24, 2010 at 11:29 am #50200ppalias
MemberMost likely there is a rule at the firewall altering the destination port. Show us the output of the commands
iptables -L -v
iptables -t nat -L -v
ifconfig
for a start and we’ll see what could be wrong.
April 26, 2010 at 1:50 pm #50201Pit
MemberHello ppalias,
here are the results:root@zeroshell root> iptables -L -v
Chain INPUT (policy ACCEPT 13 packets, 708 bytes)
pkts bytes target prot opt in out source destination
405 70508 SYS_INPUT all — any any anywhere anywhere
0 0 SYS_HTTPS tcp — any any anywhere anywhere tcp dpt:http
258 35718 SYS_HTTPS tcp — any any anywhere anywhere tcp dpt:https
40 4172 SYS_SSH tcp — any any anywhere anywhere tcp dpt:sshChain FORWARD (policy ACCEPT 218 packets, 52580 bytes)
pkts bytes target prot opt in out source destinationChain OUTPUT (policy ACCEPT 317 packets, 171K bytes)
pkts bytes target prot opt in out source destination
412 179K SYS_OUTPUT all — any any anywhere anywhereChain NetBalancer (0 references)
pkts bytes target prot opt in out source destinationChain SYS_HTTPS (2 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all — lo any anywhere anywhere
258 35718 ACCEPT all — any any anywhere anywhereChain SYS_INPUT (1 references)
pkts bytes target prot opt in out source destination
30 3966 ACCEPT all — lo any anywhere anywhere
20 6488 ACCEPT udp — any any anywhere anywhere udp spt:domain state ESTABLISHED
15 17252 ACCEPT tcp — any any anywhere anywhere tcp spt:http state ESTABLISHED
0 0 ACCEPT tcp — any any anywhere anywhere tcp spt:8245 state ESTABLISHED
29 2204 ACCEPT udp — any any anywhere anywhere udp spt:ntp state ESTABLISHED
311 40598 RETURN all — any any anywhere anywhereChain SYS_OUTPUT (1 references)
pkts bytes target prot opt in out source destination
30 3966 ACCEPT all — any lo anywhere anywhere
21 1593 ACCEPT udp — any any anywhere anywhere udp dpt:domain
15 908 ACCEPT tcp — any any anywhere anywhere tcp dpt:http
0 0 ACCEPT tcp — any any anywhere anywhere tcp dpt:8245
29 2204 ACCEPT udp — any any anywhere anywhere udp dpt:ntp
317 171K RETURN all — any any anywhere anywhere
Chain SYS_SSH (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all — lo any anywhere anywhere
40 4172 ACCEPT all — ETH04 any anywhere anywhere
0 0 DROP all — any any anywhere anywhereroot@zeroshell root> iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 40 packets, 4069 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp — ETH04 any anywhere 192.168.0.199 tcp dpt:http to:192.168.7.201:80
15 900 DNAT tcp — ETH04 any anywhere 192.168.0.199 tcp dpts:snpp:commplex-main to:192.168.7.201:444-5000
11 660 DNAT tcp — ETH04 any anywhere anywhere tcp dpt:https to:192.168.7.75:443
1 60 DNAT tcp — ETH04 any anywhere anywhere tcp dpt:ssh to:192.168.7.75:22Chain POSTROUTING (policy ACCEPT 11 packets, 923 bytes)
pkts bytes target prot opt in out source destination
92 6629 SNATVS all — any any anywhere anywhere
15 900 MASQUERADE all — any ETH03 anywhere anywhere
66 4806 MASQUERADE all — any ETH04 anywhere anywhereChain OUTPUT (policy ACCEPT 64 packets, 4932 bytes)
pkts bytes target prot opt in out source destinationChain SNATVS (1 references)
pkts bytes target prot opt in out source destinationroot@zeroshell root> ifconfig
ETH00 Link encap:Ethernet HWaddr 00:30:18:AA:BE:73
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:18 Base address:0xe000ETH01 Link encap:Ethernet HWaddr 00:30:18:AA:BE:74
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:19ETH02 Link encap:Ethernet HWaddr 00:30:18:AA:BE:75
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:16 Base address:0x2000ETH03 Link encap:Ethernet HWaddr 00:30:18:A1:71:5B
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:112 errors:0 dropped:0 overruns:0 frame:0
TX packets:131 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16099 (15.7 Kb) TX bytes:41353 (40.3 Kb)
Interrupt:23 Base address:0x6000ETH03:00 Link encap:Ethernet HWaddr 00:30:18:A1:71:5B
inet addr:192.168.7.75 Bcast:192.168.7.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:23 Base address:0x6000ETH04 Link encap:Ethernet HWaddr 00:1B:21:56:DE:97
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:607 errors:0 dropped:0 overruns:0 frame:0
TX packets:600 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:122933 (120.0 Kb) TX bytes:210159 (205.2 Kb)ETH04:00 Link encap:Ethernet HWaddr 00:1B:21:56:DE:97
inet addr:192.168.0.199 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1ETH04:01 Link encap:Ethernet HWaddr 00:1B:21:56:DE:97
inet addr:87.234.250.2 Bcast:87.234.250.7 Mask:255.255.255.248
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1VPN99 Link encap:Ethernet HWaddr 00:FF:0C:F5:78:13
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)VPN99:00 Link encap:Ethernet HWaddr 00:FF:0C:F5:78:13
inet addr:192.168.250.254 Bcast:192.168.250.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1dummy1 Link encap:Ethernet HWaddr 82:C4:47:FF:90:1B
inet addr:192.168.142.142 Bcast:192.168.142.255 Mask:255.255.255.255
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:188 errors:0 dropped:0 overruns:0 frame:0
TX packets:188 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:22023 (21.5 Kb) TX bytes:22023 (21.5 Kb)Regards
PitApril 27, 2010 at 6:26 am #50202ppalias
MemberI can see that on ETH04 you have 2 IPs aliased, one public and one private. Also on interface ETH03 you have a private address. Right so far? I suppose your wan is ETH04 and ETH03 is the lan. What is the role of ETH04:00?
Secondly I see that you are MASQUERADING on both ETH03 and ETH04, which looks wrong. Please clarify these questions and we’ll see how we will move on.April 27, 2010 at 3:09 pm #50203Pit
MemberThe public IP at ETH04 is from the former/later location. There is a range of pulic IP’s.
The private IP is at my home where i troubleshoot the balancer.ETH03 is my lan with one gateway machine. This machine and the balancer itself should be reachable over the virtual servers.
My perception of the GUI Router/NAT was, that one has to point to the both devices between NAT is supposed to be. This was obviously wrong. Additionally behind the curtain works MASQUERADING and not NAT. This is confusing too.
After some testing MASQUERADING only on device ETH04 solves the Problem.
In virtual servers also the IP wich is supposed to be used has to be configured explicitly.
Configuring the device only does not work.I thank you for your effort and the hint about MASQUERADING.
Regards
PITApril 27, 2010 at 9:19 pm #50204ppalias
MemberMasquerading is a kind of NAT, which is called PAT.
Do you still suffer from a problem on your ZS or is it working as you expected?
April 28, 2010 at 10:04 am #50205Pit
MemberIn this environment ZS works now as expected.
Now i ask before my next mismatch causes trouble:
Next step are three another lines (pppoe) balanced with the default one.
Am i right to enable NAT on this devices?
Am i right to change the default gateway to a balancer gateway?
Am i right to point the traffic to a special server with a balancer rule to a dedicated gateway?
Is it a good idea to enable rip-v.2 on all devices?
Thanks in advance
Pit
April 29, 2010 at 7:43 am #50206ppalias
MemberYou will add all the 3 pppoe lines along with the default route in the NetBalancer. You will enable NAT on them.
I am not sure what you mean to “change the default gateway to a balancer gateway”. All the PCs in your lan should use ZS as the default gateway obviously. ZS will automatically balance traffic among the configured gateways in NetBalancer.
Enabling RIP is a bad idea if don’t really need it. I don’t see why you would need it here.April 29, 2010 at 3:07 pm #50207Pit
Member… changing the default gateway to a balancer gateway….
Irefer to the first picture at ZS landingpage: Thre is the default gateway disabled and the balancer gateway Infostrada ADSL used instead.April 29, 2010 at 4:43 pm #50208ppalias
MemberOn this screenshot there are 2 more gateways apart from Infostrada. Wind and TRE, so you have 3 gateways.
May 3, 2010 at 9:33 pm #50209Pit
MemberOK. I got the idea of ZS GUI.
Thanks again for your help.Regards
PitMay 11, 2010 at 2:16 pm #50210Pit
MemberAt the production location the ZS balancer works fine over four ADSL lines.
Does somebody know the trick to administer the machine and virtual servers from remote?
VPN99 does not connect. Vitual server at :443 works only one time. After connecting to the other virtual server behind ZS the machines is no more reachable.
I guess that the answer packages are balanced to the nirwana.
Is there a way to solve this problem?
Thanks in advance
Pit
May 11, 2010 at 3:18 pm #50211atheling
Member@Pit wrote:
At the production location the ZS balancer works fine over four ADSL lines.
Does somebody know the trick to administer the machine and virtual servers from remote?
VPN99 does not connect. Vitual server at :443 works only one time. After connecting to the other virtual server behind ZS the machines is no more reachable.
I guess that the answer packages are balanced to the nirwana.
Is there a way to solve this problem?
Thanks in advance
Pit
I am interpreting “I guess that the answer packages are balanced to the nirwana” to mean that the return message packets are balanced out to the wrong interfaces. If so, have you installed the latest version of the patch mentioned on this thread.
http://www.zeroshell.net/eng/forum/viewtopic.php?t=2125
The last post has the patch, earlier in the thread is some discussion on how you can make it survive past a reboot.
May 11, 2010 at 4:55 pm #50212Pit
MemberThank you for the hint.
The patch may be not compatible:
root@zeroshell scripts> patch -p0 /dev/null
– iptables -t mangle -D PREROUTING -j NetBalancer 2>/dev/null
– iptables -t mangle -D INPUT -j NetBalancer 2>/dev/null
– iptables -t mangle -D OUTPUT -j NetBalancer 2>/dev/null
iptables -t mangle -D OUTPUT -j OpenVPN 2>/dev/null
iptables -t mangle -D POSTROUTING -m state –state NEW -j NB_CT_POST 2>/dev/null
iptables -t mangle -D POSTROUTING -j NB_STAT 2>/dev/null
if [ “`cat $REGISTER/system/net/nb/Enabled 2>/dev/null`” = yes ] ; then
iptables -t mangle -I PREROUTING 1 -j CONNMARK –restore-mark
– iptables -t mangle -I PREROUTING 2 -j NetBalancer
iptables -t mangle -I POSTROUTING 1 -m state –state NEW -j NB_CT_POST 2>/dev/null
iptables -t mangle -I POSTROUTING 2 -j NB_STAT 2>/dev/null
– iptables -t mangle -I INPUT 1 -j NetBalancer
– iptables -t mangle -I OUTPUT 1 -j NetBalancer
– iptables -t mangle -I OUTPUT 2 -j OpenVPN
fi
$SCRIPTS/nb_vpn 2> /dev/null
$SCRIPTS/nb_setautomarking 2>/dev/null
–
–
–— 1,35 —-
#!/bin/sh
. /etc/kerbynet.conf
iptables -t mangle -D PREROUTING -j CONNMARK –restore-mark 2>/dev/null
+ iptables -t mangle -D PREROUTING -m state –state NEW -j NB_CT_PRE 2>/dev/null
+ iptables -t mangle -D PREROUTING -m state –state NEW -j NetBalancer 2>/dev/null
+ iptables -t mangle -D INPUT -m state –state NEW -j NB_CT_POST 2>/dev/null
+ iptables -t mangle -D OUTPUT -j CONNMARK –restore-mark 2>/dev/null
+ iptables -t mangle -D OUTPUT -m state –state NEW -j NB_FO_PRE 2>/dev/null
+ iptables -t mangle -D OUTPUT -m state –state NEW -j NetBalancer 2>/dev/null
iptables -t mangle -D OUTPUT -j OpenVPN 2>/dev/null
iptables -t mangle -D POSTROUTING -m state –state NEW -j NB_CT_POST 2>/dev/null
iptables -t mangle -D POSTROUTING -j NB_STAT 2>/dev/null
+ # Need QoS to be done in mangle POSTROUTING. Note that if NetBalance
+ # is enabled then we will insert those rules/chains first. So any
+ # routing marks will be handled before we blow them away with QoS
+ # marks.
+ iptables -t mangle -D POSTROUTING -j QoS 2>/dev/null
+ iptables -t mangle -I POSTROUTING 1 -j QoS 2>/dev/null
if [ “`cat $REGISTER/system/net/nb/Enabled 2>/dev/null`” = yes ] ; then
iptables -t mangle -I PREROUTING 1 -j CONNMARK –restore-mark
+ iptables -t mangle -I PREROUTING 2 -m state –state NEW -j NB_CT_PRE 2>/dev/null
+ iptables -t mangle -I PREROUTING 3 -m state –state NEW -j NetBalancer
+ iptables -t mangle -I INPUT 1 -m state –state NEW -j NB_CT_POST 2>/dev/null
+ iptables -t mangle -I OUTPUT 1 -j CONNMARK –restore-mark
+ iptables -t mangle -I OUTPUT 2 -m state –state NEW -j NB_FO_PRE
+ iptables -t mangle -I OUTPUT 3 -m state –state NEW -j NetBalancer
+ iptables -t mangle -I OUTPUT 4 -j OpenVPN
iptables -t mangle -I POSTROUTING 1 -m state –state NEW -j NB_CT_POST 2>/dev/null
iptables -t mangle -I POSTROUTING 2 -j NB_STAT 2>/dev/null
fi
$SCRIPTS/nb_vpn 2> /dev/null
$SCRIPTS/nb_setautomarking 2>/dev/null
+ echo 300 > /proc/sys/net/ipv4/route/gc_min_interval
+ echo 360 > /proc/sys/net/ipv4/route/gc_timeoutAre there any further ideas?
May 11, 2010 at 4:59 pm #50213Pit
MemberOops! something went wrong.
The patch may be not compatible:
root@zeroshell scripts> patch -p0 < zeroshell-3.patch
patching file failoverd
patching file fw_initrules
Hunk #2 FAILED at 23.
1 out of 2 hunks FAILED — saving rejects to file fw_initrules.rej
patching file fw_makerule
patching file fw_start
Hunk #1 succeeded at 10 with fuzz 1.
patching file fw_viewchain
patching file nb_fw
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED — saving rejects to file nb_fw.rej
patching file nb_setautomarkingfw_initrules.rej:
***************
*** 23,34 ****
iptables -A INPUT -j SYS_INPUT
iptables -A INPUT -p tcp –dport 80 -j SYS_HTTPS
iptables -A INPUT -p tcp –dport 443 -j SYS_HTTPS
iptables -A INPUT -p tcp –dport 22 -j SYS_SSH
fi
[ “$CHAIN” == OUTPUT ] && iptables -A OUTPUT -j SYS_OUTPUT
if [ -d $CONFIG/Chains/$CHAIN/Rules ] ; then
cd $CONFIG/Chains/$CHAIN/Rules
RULES=`ls`
for RULE in $RULES ; do
ENABLED=”`cat $RULE/Enabled 2>/dev/null`”
if [ “$ENABLED” == yes ] ; then
— 23,38 —-
iptables -A INPUT -j SYS_INPUT
iptables -A INPUT -p tcp –dport 80 -j SYS_HTTPS
iptables -A INPUT -p tcp –dport 443 -j SYS_HTTPS
iptables -A INPUT -p tcp –dport 22 -j SYS_SSH
fi
[ “$CHAIN” == OUTPUT ] && iptables -A OUTPUT -j SYS_OUTPUT
+ # If we are doing the QoS chain, thenlear any marks left over from
+ # Netbalancing/failover routing. The QoS chain is applied after
+ # routing so there is no conflict.
+ [ “$CHAIN” == “QoS” ] && iptables $TABLE -A $CH -j MARK –set-mark 0x0
if [ -d $CONFIG/Chains/$CHAIN/Rules ] ; then
cd $CONFIG/Chains/$CHAIN/Rules
RULES=`ls`
for RULE in $RULES ; do
ENABLED=”`cat $RULE/Enabled 2>/dev/null`”
if [ “$ENABLED” == yes ] ; then -
AuthorPosts
- You must be logged in to reply to this topic.