click icon indicating copy to clipboard operation
click copied to clipboard

Chain NAT with IPSec

Open p4pe opened this issue 4 years ago • 2 comments

Hello everyone, I'm trying to "make" a click configuration with a NAT and an IPSec VNFs chained. Here is my configuration file:

FromDevice(eth0, HEADROOM 48, PROMISC true)
-> c::Counter
-> Strip(14)
-> CheckIPHeader()
->rw::IPRewriter(pattern 27.32.11.3 1024-65535 - - 0 1);


rw-> ipsec_rt::RadixIPsecLookup( 10.10.1.1/32 0,
192.168.2.0/32 10.10.2.1 1 111 1111111111111111 1111111111111111 1 0 ,
0.0.0.0/0 2
);

rw[1] -> Discard;

ipsec_rt[0]
// Receive
-> Discard;
ipsec_rt[1]
-> IPsecESPEncap()
-> IPsecAuthHMACSHA1(0)
-> IPsecAES(1)
-> UDPIPEncap(10.10.1.1 , 4500 , 192.168.2.5 , 4500)
-> EtherEncap(0x800,3c:fd:fe:04:ad:40, 3c:fd:fe:05:9b:80)
//-> IPPrint("Hello this is an IPSec packet")
-> Queue
-> out::ToDevice(lo);
ipsec_rt[2]
// Default
-> Discard;


My question is, if this configuration is adequate or it needs to have an IPClassifier between the rw and the ipsec_rt

Thank you

p4pe avatar Jan 28 '21 17:01 p4pe

If the goal is just to just simply 'chain' elements together for throughput testing then there would be no need for IPClassifier, since this is used to match traffic and output the matched traffic to different output ports. A simple example would be to say split UDP and TCP traffic. Another valid use of IPClassifier in this example config would be after CheckIPHeader and before IPRewriter. With the classifier there you would be able to filter say only traffic matching the source or sink destination which helps to avoid getting some L2 noise on the network into the rest of the config.

If adequate means to have a real world setup, then I would say no. Running NAT on the traffic then encrypting with IPsec , then tunneling in UDP encap is not a practical/logical sequence for a real setup.

ahenning avatar Jan 29 '21 08:01 ahenning

Hello @ahenning, yes the adequate means, if this is ok for just thoughput testing.

p4pe avatar Jan 29 '21 09:01 p4pe