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.
Exactly! > 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. This is where I am confused! On the DCD firewalls, we have the tcpdump.lrp included w/DCD -- version 3.5. I have compiled v3.6.2 on my development box. Do *both* qualify as ``Recent versions''? If so, how do we accomplish what you outline in your last sentence? Notice, that 192.168.1.254, in my first example, is a DCD firewall/gateway with eth0 as the external interface. The DCD firewall/gateway on the other end has wanpipe as external interface, so I don't want to complicate matters -- right now -- with that variable ;> The fact that tcpdump output, for icmp on ipsec0 for this DCD firewall/gateway, clearly shows ``feed face dead beef'' disturbs me ;< What are we missing? > If you can't get a recent enough tcpdump (I haven't had need to test IPSec > this way), if your upstream link is ethernet (ie cable/xDSL), you can > "listen in" on the traffic even if you've only got one IP. Just hook a > system with an ethernet NIC up to your upstream link (you'll probably need a > 'hublet' or similar to get all 3 NIC's talking)...another LEAF system will > work OK. Instead of configuring the external interface on your test box, > just enable it with "ip link set dev eth0 up" and run tcpdump. The > interface will go into promiscuous mode, and recieve all traffic, even > though it dosn't have an assigned IP, allowing you to sniff the actual > traffic on the wire. Once we accomplish your first scenario, then this is moot -- Otherwise, we may need to go this route . . . 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
