[Leaf-user] DCD, ipsec & tunnel testing ???
OK, I'm getting the hang of this -- happy new year! 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 Then, I goto the other side (192.168.1.254, the remote DCD firewall/gateway) and do this: tcpdump -tx icmp However, I get this: tcpdump: listening on ipsec0 192.168.1.20 > 192.168.123.110: icmp: echo reply 4500 0054 664b 7f01 d78a c0a8 0114 c0a8 7b6e ff15 6d42 3c31 6ffe 5b58 feed face dead beef feed face dead beef feed face dead beef feed face dead beef But, I never get any echo requests! If I do this: ping -p feedfacedeadbeef 192.168.123.130 from 192.168.123.110 and do this: tcpdump -tx icmp from 192.168.123.130, then I see this: tcpdump: listening on eth0 192.168.123.110 > 192.168.123.130: icmp: echo request 4500 0054 3ea7 4001 c3c0 c0a8 7b6e c0a8 7b82 0800 42fd 7142 3c31 701a 0008 0b4d feed face dead beef feed face dead beef feed 192.168.123.130 > 192.168.123.110: icmp: echo reply 4500 0054 f096 ff01 52d0 c0a8 7b82 c0a8 7b6e 4afd 7142 3c31 701a 0008 0b4d feed face dead beef feed face dead beef feed 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? 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 ???
> 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 > > > 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. 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. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ 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 > > > > > > > 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 ???
> > 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... > 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 ;< Unnecessarily so...ipsec0 is the "in-the-clear" interface for IPSec traffic. Un-encrypted traffic is routed to (and comes from) ipsec0. The kernel code encrypts outbound traffic from ipsec0, which eventually winds up being transmitted as protocol 50 (or 51) traffic on eth0 (or wan0, or whatever your upstream interface is). Recieve traffic is the same...it shows up encrypted on eth0, and is spit out un-encrypted by ipsec0. See the packet flows provided by Hugh Redelmeier at: http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/firewall.html#dhr Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ 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 > > > > > > > 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
Re: [Leaf-user] DCD, ipsec & tunnel testing ???
> 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? Yes, this is a valid test. There are only a few things I can think of to test more completely: 1) Use a non-gateway system to sniff the traffic...this will guarantee you're getting a true picture of exactly what's on the wire 2) Decrypt the IPSec packets and verify they acually contain the expected data 3) Send 'in the clear' pings with the same or content to a unique host to verify your packet capturing and result extraction methods are working as expected You should at least be able to do #3 pretty easily. You'll have to decide if the extra verification provided by #1 and #2 are worth the hassle... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
