IPsec NULL Encryption & NULL Authentication

Have you ever wanted to test an IPsec tunnel but wanted to see the packets in clear text instead of all those encrypted gibberish stuff? One of the ways and to me the easiest one is to use NULL encryption. In this post we will see how we can leverage this no encryption method. Below is our topology.


We will first enable NULL encryption and then see what it means practically for us. I am not sharing entire config but only show what we need to enable this.

Yes that is it! We have enabled NULL encryption. Setting NULL encryption means actually not setting any encryption-algorithm under IPsec proposals. If you leave it empty, your ESP encapsulated packets won’t be encrypted. You don’t believe me? Let me show you.

Now I hope you believe me now. Still don’t? Let me show you then in wireshark. First send ping PC2 from PC1 and capture ESP traffic on the wire.

Below is the screenshot of the captured traffic.


but we still see the ESP payload and nothing in clear text. The trick is that we must tell Wireshark to decode this NULL encrypted payload. As you can see in the following screenshot under protocol preferences, you can do this.


and finally we have the clear text ICMP traffic. We can clearly see the inner IP header and payload. This is really cool if you want to troubleshoot ESP packets.


The title of the post also mentions about NULL authentication Actually the method to enable NULL authentication is also similar to NULL encryption but with a trick. If you want to disable authentication, then it is sufficient not to set the authentication as below.

but did you notice this time, I have enabled encryption. The trick is you can’t disable both. You can but if you do, IPsec assigns the default encryption method 3des and default authentication sha1.

I have found the answer in RFC2401 from which I have quoted the relevant text.

I believe IPsec is easier once you know about NULL encryption. If you want to read Juniper documentation about this see the following:

You find this method cool, then let me know!

2 thoughts on “IPsec NULL Encryption & NULL Authentication

  1. jbrantley39

    Pretty cool stuff, definitely useful for when in the lab. Don’t know how well that would go over if you were doing it over the internet with production data though. Maybe you could use it to get the tunnel up and just verify data is transversing correctly before putting in real data. I went in search for other reasons you might want to do this. RFC2410 (so close to the one you mentioned, so I had to double check) goes over the NULL encryption as well and makes it seem like you can make it act just like AH but within ESP and that it is faster than AH. Another post here https://routingfreak.wordpress.com/tag/esp-null/ basically says the same thing and that AH should be retired. I don’t see that happening, but cool to see you can do this.

    1. rtoodtoo Post author

      Thanks for reference to the RFC2410. It was really missing in this post. Actually in my opinion with the right configuration you can try NULL encryption without interrupting production traffic. For example, if a test is to be done between two protected end points, than a new /32 proxy-id SA would be brought up and through this new tunnel, ESP traffic could be tested.
      I haven’t tested this but I think it should work. It would be really useful to test high CPU issues or encryption related performance degradation.
      This would probably require FBF (policy based routing too) to handle routing part.

      Thanks for the valuable feedback, appreciated.



You have a feedback?

This site uses Akismet to reduce spam. Learn how your comment data is processed.