This is something that grind my gears: Limitations of the IPSec implementation, and lack of how-tos about the specifics at the title of this post.
That situation lead me to this “not so beautiful” solution, where i use client certificates do identify the peers.
Every time i’ve tried to create a site-to-site environment where the remote office had to forward everything to the main office (basically 0.0.0.0/0
) before going to the internet i had to deal with these issues:
And after some days of lab, here is my recipe:
My scenario while developing this solution was:
1.2.3.4
as external ip A
entry for ipsec.example.net
;0.0.0.0/0 - 10.1.0.0/16
. This /16
net will take care of all /24
networks inside the remote office;Things i will not deal or explain on this article:
10.1.0.0/16
- gw 172.16.2.1
. so, internal services(intranet, webmail, etc) can be reached;A little diagram
INTERNET
^
ISP LAN: |
192.168.1.0/24 | +--------------------+
+-----------+ | +-----------+ |DATACENTER |
| OPNSense | | |Proprietary+---^-+172.16.0.0/16 |
| Remote +----------+-->+ FW | | |(multiple /24 Vlans)|
| Office |ipsec.example.net -1.2.3.4| | +--------------------+
+-----+-----+ + +-----------+172.16.2.254/24
| | |
+-----+-------+ v-----NAT------+WAN:172.16.2.1/24
|Internal NETS| +------------+ |
|10.1.10.0/24 | | OPNSense | |
|10.1.11.0/24 | |Main Office +--+
|10.1.12.0/24 | +------------+
|10.1.13.0/24 |
|etc. |
+-------------+
It’s chaotic but i hope you get it. If you can’t grok the /16
and /24
net-subnet relationship:
Site A: Our main office. Site B: Our remote office.
These keywords/terms will be interchangeably used.
You will basically create a CA, Site A and Site B client certificates both signed by the same CA.
All these artifacts will be generated inside the Site A OPNSense trust management.
You will export the CA(without keys) and Site B certificate(with keys) and import both at the Site B.
Access your OPNSense Site A(main office) web management interface.
CA_IPSEC_SITE2SITE
seems to be good enough3650
days(almost 10 years), to avoid dealing with expired CAsBR Brazil
noc@example.net
or postmaster@example.net
)ipsec-ca
MAIN_OFFICE_IPSEC
seems to be good enough3650
. You can revoke this certificate if anything wrong or a security incident happens.site2site@example.net
since doesn’t have to be a valid email address, but it will be used as identifier.COMPANY_CITY
(CITY = IATA code) or anything you likesite2site@example.net
in this case)
Still while accessing Site A Trust management(cause it’s where the CA resides)
OFFICE01_IPSEC
seems to be good to me3650
office01@example.net
COMPANY_CITY
or anything you likeoffice01@example.net
in this case)Access your OPNSense Site B(Remote office) web management interface.
CA_IPSEC_SITE2SITE
to keep information the sameNow, import the client certificate using the same logic(is not that hard…)
OFFICE01_IPSEC
Now we will setup the tunnels that will connect remote and main office. It’s pretty straightforward:
10.1.0.0/16
will be your remote network to Site A and local network to Site B0.0.0.0/0
will be your remote network to Site B and local network to Site AAccess your Site A management interface.
Phase 1:
ipsec.example.net
(1.2.3.4
) pointing to our wan IP (172.16.2.1
).0.0.0.0
(means, anyone)SITE2SITE_OFFICE01
is my suggestion since each Phase 1 will correspond to one officesite2site@example.net
office01@example.net
28800
Phase 2:
0.0.0.0/0
10.1.0.0/16
Thats it. The server is listening to connections and waiting someone to connect using a valid certificate.
Access your Site B management interface.
Phase 1:
ipsec.example.net
OFFICE01_SITE2SITE
is my suggestion.office01@example.net
site2site@example.net
28800
30
seconds 3
retries. This will make IPSec reconnect in case of connectivity loss.Phase 2:
10.1.0.0/16
0.0.0.0/0
Important: Do not apply settings yet. First, we will tweak the local lans
Access IPSec advanced settings:
/24
internal networks on your remote office plus, the LAN network connected to your ISP. This will make local traffic use a pass
ipsec connection type on, keeping local traffic inside your remote office.
10.1.10.0/24
10.1.11.0/24
10.1.12.0/24
10.1.13.0/24
… 192.168.1.0/24
If you don’t create those passthrough networks, all local traffic (example, 10.1.12.100
is a voip phone, 10.1.13.200
is an asterisk server) will be redirected to your main office.
Another example: If your OPNSense remote office box is also a dhcp-relay to a Active Directory VM on that office, all traffic will be forwarded through ipsec if no passthrough network is declared.
After all this configuration, you should be able to connect both offices.
Taking a look at Site B logs(VPN > IPSec > Log File), you should find something like this:
charon: 04[IKE] <con1|1> peer supports MOBIKE
charon: 04[IKE] <con1|1> CHILD_SA con1{1} established with SPIs c69c3961_i ceca7713_o and TS 10.1.0.0/16 === 0.0.0.0/0
charon: 04[CFG] <con1|1> selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
charon: 04[IKE] <con1|1> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
charon: 04[IKE] <con1|1> IKE_SA con1[1] established between 192.168.1.9[office01@example.net]...MAIN.OFFICE.IP.ADDR[site2site@example.net]
charon: 04[IKE] <con1|1> authentication of 'site2site@example.net' with RSA_EMSA_PKCS1_SHA2_256 successful
charon: 16[IKE] <con1|2> peer supports MOBIKE
charon: 16[IKE] <con1|2> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
charon: 16[IKE] <con1|2> authentication of 'office01@example.net' with RSA_EMSA_PKCS1_SHA2_256 successful
Site A logs as soon as you start ipsec.
charon: 14[CFG] added configuration 'con1'
charon: 14[CFG] loaded certificate "C=BR, ST=STATE, L=City, O=My Org, E=site2site@example.net, CN=COMPANY_CITY, subjectAltName=email:site2site@example.net" from '/usr/local/etc/ipsec.d/certs/cert-1.crt'
charon: 14[CFG] received stroke: add connection 'con1'
charon: 00[JOB] spawning 16 worker threads
Can you see that subjectAltName=email:
and E=
are exactly the same?
Site A logs right after Site B connects(supressing sensitive and Certificate specific info with ...
since is too much to replace):
charon: 16[IKE] <con1|2> CHILD_SA con1{2} established with SPIs cacde5b5_i c8397929_o and TS 0.0.0.0/0 === 10.1.0.0/16
charon: 16[CFG] <con1|2> selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
charon: 16[IKE] <con1|2> sending end entity cert "..."
charon: 16[IKE] <con1|2> IKE_SA con1[2] established between MAIN.OFFICE.IP.ADDR[site2site@example.net]...REMOTE.OFFICE.IP.ADDR[office01@example.net]
charon: 16[IKE] <con1|2> authentication of 'site2site@example.net' (myself) with RSA_EMSA_PKCS1_SHA2_256 successful
charon: 16[IKE] <con1|2> peer supports MOBIKE
charon: 16[IKE] <con1|2> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
charon: 16[IKE] <con1|2> authentication of 'office01@example.net' with RSA_EMSA_PKCS1_SHA2_256 successful
charon: 16[CFG] <con1|2> using trusted ca certificate "..."
charon: 16[CFG] <con1|2> using certificate "..."
charon: 16[CFG] <con1|2> selected peer config 'con1'
charon: 16[CFG] <2> looking for peer configs matching MAIN.OFFICE.IP.ADDR[site2site@example.net]...REMOTE.OFFICE.IP.ADDR[office01@example.net]
charon: 16[IKE] <2> received end entity cert "C=BR, ST=State, L=Remote Office City, O=My Org, E=office01@example.net, CN=COMPANY_SITEB_CITY, subjectAltName=email:office01@example.net"
Pretty simple eh?
That’s all. Hope you have enjoyed.