click
click copied to clipboard
Chain NAT with IPSec
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
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.
Hello @ahenning, yes the adequate means, if this is ok for just thoughput testing.