Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chain NAT with IPSec #478

Open
p4pe opened this issue Jan 28, 2021 · 2 comments
Open

Chain NAT with IPSec #478

p4pe opened this issue Jan 28, 2021 · 2 comments

Comments

@p4pe
Copy link

p4pe commented Jan 28, 2021

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

@ahenning
Copy link

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.

@p4pe
Copy link
Author

p4pe commented Jan 29, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants