VPN revisited.

[Peter Warasin]

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