VPN revisited.
Peter Warasin
peter at endian.com
Fri Aug 22 10:33:28 UTC 2008
Hi David
wlanmac wrote:
> Since you are doing so many tests, it would be great to see your results
> in a spreadsheet noting each test's parameters.
Well, had should think about that before :/
>> That's wired. Maybe it was only luck? Sometimes it works also for me
>> without special iptables rules. But most of the time it doesn't.
>> Have you tried to connect/disconnect/connect/disconnect all the time?
> I would guess that constantly connecting and disconnecting would
> confused Windows more than the firewall. ;)
I guessed that too, but no, without chilli and with the pptp helpers
loaded you can connect/disconnect all the time. That's working without
problems.
> So, you are saying that you never have trouble with one VPN passing
> through? No matter what modules you use?
No.
Without pptp modules you can have exactly 1 pptp connection which is
working always fine. As soon as you start a second connection it does
not work anymore. That's quite normal, with and without chilli.
With chilli pptp most of the time does not work with kernel modules,
without kernel modules the first connection works always.
creating that notrack rules all work fine.
> The notrack rules for the dhcpif should probably help if the helpers are
> getting confused. I wonder if conntrack sees all packets (unless told to
> not track in the raw table) even if they are DROP'ed during INPUT on the
> device. Can you also DROP from the raw table? hmm..
It's not enough to drop only in the filter table in order to hide the
packets from netfilter.
The packets flow through every netfilter "table" (raw, mangle, nat,
filter, nat). There are actually way more such tables, which you can't
see with iptables.
The tables in reality are entries in a callback array. A packet goes
through a number of callback handlers (14 hardcoded) and other modules
may insert their own callback handlers (for example LVS does).
Dropping a packet in one of those callback handlers, the filter table
for example does not mean that it does not go through any other callback
handler. It means only that it stops going through rules within that
callback handler, the filter table in our case.
The filter table can only drop and accept packets, which should not harm
nor help chilli, while the mangle and nat table are those which actually
can change packets, which can destroy things.
I see no possibility to completely shut down netfilter completely for a
specific device, probably that is what should be done in the first place
in order to give the packets to chilli in exactly that condition as they
arrived.
So I think one need also to manually make rules which make exceptions
for the dhcpif in the mangle and nat table whenever one has entries there.
peter
--
:: e n d i a n
:: open source - open minds
:: peter warasin
:: http://www.endian.com :: peter at endian.com
More information about the Chilli
mailing list