Charles Steinkuehler wrote:
>
> > Anyway, I have a tunnel between two (2) Dachstein-CD firewall/gateways,
> > seperated by the big, bad internet ;>
> >
> > I remain confused, however, *how* to test the encryption. Yes, I
> > understand how, if both boxes were local and I could place a 3rd in
> > between; but, I cannot do that here.
> >
> > While I'm on 192.168.123.110 (not a DCD firewall/gateway) I do this:
> >
> > ping -p feedfacedeadbeef 192.168.1.20
> >
> <snip>
> >
> > Yes, I know that the FreeS/WAN FAQ emphatically states that this
> > scenario, testing with tcpdump on either gateway, will be confusing;
> > but, however else can I test this setup?
>
> Well, your existing tests have shown your network is connected, so what you
> really need to verify is that the data between your endpoints is really
> encrypted. Recent versions of tcpdump are smart enough to be able to dump
> the encrypted traffic going over the physical interface without being
> confused. You basically want to dump the raw traffic going over your
> external 'net, and verify protocol 50 packets are being sent/recieved, and
> that the packets don't contain anything that looks like your
> "feedfacedeadbeef" ascii string.
[ snip ]
Or, is this what should be done?
Note: a.b.c.157 is the public address to 192.168.1.0/24 internal
network; and, x.y.z.86 is the public address to 192.168.123.0/24
internal network.
>From come client on the x.y.z side:
# ping -p feedfacedeadbeef 192.168.1.20
Then, this from the DCD gateway/firewall on the x.y.z side:
# tcpdump -tx -i eth0 'ip proto 50 or ip proto 51'
tcpdump: listening on eth0
x.y.z.86 > a.b.c.157: ESP(spi=3579401720,seq=0x20)
4500 0088 0dab 0000 4032 43a9 0cf8 fd56
4004 de9d d559 55f8 0000 0020 f33f 3366
8f63 3b3e 155a 882f 523d a640 4d78 c0fc
b7c2 9fef fb6a
a.b.c.157 > x.y.z.86: ESP(spi=2227707313,seq=0x1d)
4500 0088 2791 0000 3132 38c3 4004 de9d
0cf8 fd56 84c8 1db1 0000 001d ad4a 7c23
e4bf 0ceb bc45 0a55 8b3f a3a0 230f dfcc
0b6e 7ef8 3987
Notice, that this is tcpdump v3.5 and that we are now listening on eth0,
*not* ipsec0.
Is this _proof_ that encryption is working?
What do you think?
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is inversely proportional to how much we
think we know. The more I know, the more I know I don't know . . .
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
