|
Hello,
On Thu, 15 Jun 2000, Clint Byrum wrote:
> This thing is a pretty complicated firewall(yes I know that means it could
> be something else affecting this), and has quite a few ipchains rules. Which
> types of things were you thinking of? Here are some of the pertinent
> commands:
>
>
> The forward chain has these two rules(among others)
> ipchains -A forward -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT
> ipchains -A forward -s 192.168.10.0/24 -j MASQ
> ipchains -A forward -s 192.168.1.0/24 -j MASQ
I assume this is the right order of your rules.
>
> For the portfw serviced example:
> ifconfig lo:14 $EXTIP netmask 255.255.255.255
> ipmasqadm portfw -a -P tcp -L $EXTIP 80 -R 192.168.10.4 80
>
> For the ipvs services example:
> ifconfig lo:10 $EXTIP netmask 255.255.255.255
> ipvsadm -A -t $EXTIP:80 -s wlc -p
> ipvsadm -a -t $EXTIP:80 -r 192.168.10.2:80 -m
> ipvsadm -a -t $EXTIP:80 -r 192.168.10.3:80 -m
>
> What else do you need?
tcpdump where the rewritten packets from portfw are
shown. I can't understand why they are rewritten with saddr=EXTIP.
Your packets are masqueraded only when daddr (client) is not in
192.168. Both portfw and LVS/NAT must demasq them but they are
not masqueraded when forwarded to the 192.168 clients. I don't
believe these TCP connections are established. Show us a
tcpdump output.
I think, the only way your setup to work is when
using VS/DR or VS/TUN but not VS/NAT or portfw. For the
clients not in 192.168 you can use any forwarding method.
It is not correct to demasq packets which are not
masqueraded in the reverse path (in -> client). Your client
is confused. The client sends packet 1.255 -> EXTIP and
the reply is 10.2 -> 1.225. Your first forward rule disables
the masquerading from 10.2 to 1.225.
What do you think, is there a difference if the client is
1.225 or 10.200 when accessing same EXTIP in 192.168.10? Why 10.200 will
not work and 1.225 should work in your setup? You don't masquerade to both
addresses when they are used as clients.
Once a portfw or LVS/NAT create entry after the first
packet is demasqueraded this is not a reason this connection to
be masqueraded. portfw and LVS/NAT define what is demasqueraded
but ipchains determine what is masqueraded.
The rule when using MASQ is: the forwarding rule to your clients
must be MASQ and not ACCEPT.
Is this correct?
>
> > the output of netstat -Mn gives these selected entries:
> >
> > tcp 44:56.77 192.168.10.4 192.168.1.225 80 -> 1645 (80)
> > tcp 5:40.65 192.168.10.2 192.168.1.225 80 -> * (80)
> > tcp 0:49.65 192.168.10.2 192.168.1.225 80 -> 1643 (80)
I don't see difference in the netstat -Mn. LVS just
creates one additional entry (template) for the client (the
2nd line with dport=0, with *).
I don't see why this difference is in 0.9.9+ (0.9.12).
If your output is from LVS 0.9.8 I can understand why the portfw
entry has such long timeout. This value is very strange in
0.9.12: 44:56.77. The LVS 0.9.9 changed the state transition
from SR->ES on SYN+ACK to SR->SR. Is the portfw connection
really established or this is an output before 0.9.9? May be you
tested with version < 0.9.9 (no success) and then switched to
0.9.12 (again without success) and then show us this output?
There is something I don't understand. Please, explain.
Regards
--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
|
