I just recently stroke a TNSR update cert and upgrade my virt-appliance to 19.08. The upgrade went fine , but I had numerous issues afterwards with the config daemon, which needs further investigations.
The vpn-IPSec configurations are very simple, but you need to watch all items in the configuration at the TNSR cli to ensure completeness
1st the FortiOS ( plain jane route-base-configuration ......nothing is complex here )
A few items to point out.
- This is a route-based vpn and a route was used for the TNSRnew interface
- I defined phase1-idtype as fqdn and a simple value of "fgt.socpuppets.com"
- I used the onboard wizard and cisco to build a basic configuration and later, I made changes to the proposals
The TNSR has a lot more work but the configuration is straight forward. Here's the snippet of the xml dump of the configuration
The configuration can be dump as "show configuration running" from the CLI
But to get to that cfg you have to do a few items; You can follow the IPSec example at the support site to get an idea of the items that need configuring for IPSEC.
Ensure you set the IKE version for version 1 or 2 and to match the FortiOS value that you defined in the FGT.
https://docs.netgate.com/tnsr/en/latest/ipsec/example.html
Now for diagnostic and if the needs should come up for trouble-shooting;
FortiOS
diag sniffer packet <interface name > "udp 500 or 4500"
diag debug enable
diag debug application ike 10
diag vpn tunnel list
diag vpn ike gateway
TNSR
Here we the show ipsec tunnel verbose cmd and the logs located at /var/log/messages will show IPSec logs details ( Strongswan is the IPSec engine for TNSR , btw )
https://en.wikipedia.org/wiki/StrongSwan
To get to the logs you should do the following from the tnsr-cli-cmds by opening a shell
shell
sudo tail -n 40 /var/log/messages
Here are some screenshots from the Fortigate on a FGT-2-TNSR setup
phase1 details
phase2 details
NOTE: The SPI values for in/out would match the TNSR out/in
TNSR ike and child SecurityAssociations details;
Take note of the local and remote identities for the two end-points. These are mandatory for AWS since the Elastic IP and interface IP are not the same. I used a "fqdn" type with a simple entry. The FQDN does NOT need to exist in DNS btw.
e.g
Here our tnsr "show ipsec tunnel verbose" output executed from the cli
and a TNSR log file would look like the following;
TNSR interfaces from centOS bash shell for this demo AWS instance
You can learn more about TNSR at the following link, Netgate's TNSR
https://www.tnsr.com
They have software and appliances that can drive 100gbps or more and with hardware CPUs that can push 14Mpps per core. The folks at Netgate have built this system for mainly cli or api usage. I will post more about the API usages later, and along with examples.
No comments:
Post a Comment