parallel encrypted and unencrypted tunnels
-
Two types of traffic flow between two locations:
• ordinary traffic that should be encrypted over the WANs
• time-critical, low delay audio traffic that can be sent in the clear over the WANs.Both locations run Netgates with pfSense, and share a common 10.0.0.0/8 address space.
Location A: 10.32.0.0/12, divided as follows
- destinations that should receive their traffic encrypted: 10.32.0.0/13 (A-encrypt)
- destinations that should receive their traffic clear: 10.40.0.0/13 (A-clear)
Similarly, at location B: 10.160.0.0/12
- 10.160.0.0/13 destinations receive encrypted traffic (B-encrypt)
- 10.168.0.0/13 destinations receive clear traffic (B-clear)
The attempted IPsec IKEv2-based solution:
• Phase 1 IKEv2 with a pre-shared key for auth and encrypted phase 1 exchange.
• four phase 2 child SAs:
– A-encrypt to B-encrypt
– A-clear to B-encrypt
– A-encrypt to B-clear
– A-clear to B-clear
The last child uses AH only.This doesn't seem to work. Looking at the status/IPsec section seems to show that the subsequent tunnels get set up with aggregates of the address spaces from above, and the traffic doesn't flow, or doesn't flow as intended in the clear (AH-only) tunnel.
Other attempts to aggregate addresses in the child definitions were similarly unsuccessful in exchanging traffic as well; e.g.,
10.32.0.0 site:
10.160.0.0 site:
resulted in the following when a device at 10.33.0.2 attempted to contact 10.160.0.1 and 10.169.1.1 in the far end encrypted and clear address ranges:
No response was obtained from the far end... and it appears all the address subnets were combined into a single tunnel with encrypted traffic.
Similarly clear subnet to clear subnet communications did not occur.
Suggestions?
Do I need to create multiple phase 1 relationships between the same pair of sites to isolate the traffic flows into the correct type of tunnel?
-
@eric-scace Last point: Everything works fine if there is only one Phase 2 definition for the full subnet at each site — except, of course, all traffic gets encrypted.
Another way of looking at this problem: How does one take a tunnel between two sites that encrypts traffic (10.32.0.0/12 ︎ 10.160.0.0/12)... and divert traffic between a specific subset pair of address ranges (source & destination... in this example 10.40.0.0/13 ︎ 10.168.0.0/13) to be sent (potentially through a different tunnel) in the clear?