Re: [Leaf-user] DCD, ipsec tunnel testing ???
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
Re: [Leaf-user] DCD, ipsec tunnel testing ???
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 4032 43a9 0cf8 fd56 4004 de9d d559 55f8 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 3132 38c3 4004 de9d 0cf8 fd56 84c8 1db1 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
Re: [Leaf-user] DCD, ipsec tunnel testing ???
Charles Steinkuehler wrote: 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''? I don't know...I don't try to sniff IPSec packets on the gateway systems...I use a seperate box. Info should be in the FreeS/WAN list archives, or online docs... If so, how do we accomplish what you outline in your last sentence? Um...dump the traffic from eth0, and verify you don't see any feedfacedeadbeef strings. You'll probably want to log everything, and verify you're seeing encrypted protocol 50 packets, and NOT seeing any unencrypted pings. For extra credit, you can use manual keying, provide tcpdump with the keys, and decrypt the IPSec traffic... [ snip ] OK, I received your post *after* my last post, in which I sniffed eth0 for all packets related to protocols 50 51. Subsequently, I realized that my attempt only demonstrated contents of packets for those protocols ; So, I did same ping; but, now I sniffed the external (eth0 wan1, *not* ipsec0) interfaces on *both* ends for *ALL* packets (Note: *no* expression), logged output to a file on each gateway/firewall for ten (10) minutes of pinging, then: grep -i 'feed\|face\|dead\|beef' /tmp/dump.out On one side, there was one instance of 'feed'; but, analysis showed that this was coincidental and between that gateway/firewall and some other point on the internet. Otherwise, all output was clean and apparently random. Is this a valid test? 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
