Messages

Right, except we can't specify 'route all traffic except 192.168.1.0/24'.
I had reviewed my firewall rules before posting here and did not find anything related to the issue. I'd even tried disabling all rules to make troubleshooting easier.

And if the IPsec routing is done via kernel policy, pf isn't going to show it.
Thanks for your insights, I appreciate it.

Add RADIUS support for IPsec authentication and accounting.

Currently IPsec supports just PSK and RSA, since we currently already support adding external RADIUS servers, let strongSwan forward authentication and accounting traffic to the same RADIUS server if selected.
FreeRADIUS and Microsoft NPS are tested as working by strongSwan and shouldn't be too much effort to integrate.

This would require strongswan be compiled with '--enable-eap-radius'. Specify the RADIUS server IP + auth and accounting port in '/usr/local/etc/strongswan.d/eap-radius.conf' and set 'rightauth=eap-radius'.

strongSwan also supports DAE with RADIUS.
'The Dynamic Authorization Extension allows a RADIUS backend to actively terminate a session using a Disconnect-Request, or change the timeout of a session using a Session-Timeout attribute in a CoA-Request. The extension is enabled using a dae section in the eap-radius configuration.'

See https://wiki.strongswan.org/projects/strongswan/wiki/EAPRAdius

@Strykar fail2ban like functionality for the webgui and ssh is enabled by default in OPNsense (https://github.com/opnsense/sshlockout_pf).
After 15 retries it locks the ip address using two aliases (sshlockout, webConfiguratorlockout).

Nice! Any chance this could be made port/application agnostic and configurable via the web interface? It could then be used for slowing down brute force attempts of any network facing services.

It totally seems like LAN traffic is sent out via the IPsec interface, although this can't be the intended behavior?

Sorry I should've posted basic network test results.
192.168.1.2 is directly connected to LAN on the router (igb0) so it is just 1 hop away.

Here it's working without any IPsec tunnel established:

root@opnsense:~ # ipsec status
Security Associations (0 up, 0 connecting):
  none

root@opnsense:~ # ping -qc4 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes

--- 192.168.1.2 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.300/0.369/0.445/0.052 ms

root@opnsense:~ # traceroute -m 5 -i igb0 -I 192.168.1.2
traceroute to 192.168.1.2 (192.168.1.2), 5 hops max, 48 byte packets
1  192.168.1.2 (192.168.1.2)  0.485 ms  0.254 ms  0.204 ms
root@opnsense:~ #

And after the tunnel is established:

root@opnsense:~ # ipsec status
Routed Connections:
        con1{1}:  ROUTED, TUNNEL, reqid 1
        con1{1}:   192.168.1.0/24 === 0.0.0.0/0
Security Associations (1 up, 1 connecting):
   (unnamed)[2]: CONNECTING, 111.120.36.160[%any]...155.99.25.7[%any]
        con1[1]: ESTABLISHED 18 seconds ago, 111.120.36.160[C=US, ST=NYC, L=ALB, O=PSTO PKI/emailAddress=xxx@xxxxx.xx, CN=xxx.xxxxx.xx]...155.99.25.7[155.99.25.7]
        con1{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: xxxx519a_i xxxxd40b_o
        con1{2}:   192.168.1.0/24 === 0.0.0.0/0

root@opnsense:~ # ping -qc4 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes

--- 192.168.1.2 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

root@opnsense:~ # traceroute -m 5 -i igb0 -I 192.168.1.2
traceroute to 192.168.1.2 (192.168.1.2), 5 hops max, 48 byte packets
1  * * *
2  * * *
3  * * *
4  * * *
5  * * *
root@opnsense:~ #

tcpdump at Site B shows no ICMP traffic so it'd appear to not reach there.

[Site A]

Hi,

This is my setup, both sites are using OPNsense:

Site A
ADSL dynamic IPv4 WAN which is also a gateway to 2 LANs - LAN A(192.168.1.0/24) + LAN B(192.168.2.0/24)

Site B
Static public IPv4 + global IPv6. 2nd NIC connects a 10.x LAN but this machine does no NAT for its LAN.
As suggested by the howto doc linked below, it does do outbound NAT for Site A's LAN A+B.


I wish to tunnel all Internet traffic from both LAN subnets at Site A via Site B.
I've used https://goo.gl/0YriHL as a reference and it works using IKEv1 PSK.

My issue is that all inter-LAN access at Site A is lost when the tunnel goes up.
Machines in LAN A cannot ping or access machines in the same LAN. Same for LAN B.
While none of the LAN machines can ping each other, all traffic is correctly sent out via Site B.

These are the NAT rules at Site A.
A diff before and after the tunnel is established shows no change in them.

# pfctl -sn
no nat proto carp all
nat-anchor "natearly/*" all
nat-anchor "natrules/*" all
nat on pppoe0 inet from 127.0.0.0/8 to any port = isakmp -> 182.70.11.137 static-port
nat on pppoe0 inet from 192.168.1.0/24 to any port = isakmp -> 182.70.11.137 static-port
nat on pppoe0 inet from 192.168.2.0/24 to any port = isakmp -> 182.70.11.137 static-port
nat on pppoe0 inet from 127.0.0.0/8 to any -> 182.70.11.137 port 1024:65535
nat on pppoe0 inet from 192.168.1.0/24 to any -> 182.70.11.137 port 1024:65535
nat on pppoe0 inet from 192.168.2.0/24 to any -> 182.70.11.137 port 1024:65535
no rdr proto carp all
rdr-anchor "relayd/*" all
no rdr on igb0 proto tcp from any to (igb0) port = http
no rdr on igb0 proto tcp from any to (igb0) port = ssh
rdr-anchor "miniupnpd" all

The rather large diff between firewall rules (pfctl -sr) before and after the tunnel is established is at https://dl.dropboxusercontent.com/u/314525/rules.diff

• Where do I start to troubleshoot this?
• Is there any documentation to migrating this setup from IKEv1 PSK to IKEv2 RSA pubkey?

Perhaps of useful note is the fact that road warrior RSA pubkey auth works fine at both sites.

fail2ban plugin - especially useful for those of use using it in a hosted VM and have to enable HTTPS WAN access. Currently I've moved the HTTPS port from 443 to keep script kiddies out, a configurable fail2ban would be useful to those testing to deploy on Linode/DO.

And it's a great plugin that's useful for almost every public facing network service.

Most CPUs come with AES-NI instructions and this will provide superior performance when using AES VPNs. The days of addon cards for VPN are over with such CPUs as these cards only serve to increase latency today - PCI bus to CPU and back.
Get a CPU with AES instructions instead.

A Compex WLE200NX should work out of the box - http://www.compex.com.sg/product/wle200nx/
The 600VX should work in FBSD 11, while the 802.11ac 900VX drivers will be iffy for a while to come.

An external AP will prive much better performance and you don't have to worry about driver support, I like Ubiquiti products - https://www.amazon.com/Enterprise-System-UBIQUITI-NETWORKS-UAP-LR/dp/B00HXT8S9G/ref=sr_1_6?s=pc&ie=UTF8&qid=1472901398&sr=1-6

I tested IPFire, PFsense and OPNsense for 2 weeks as VMware guests on my APU2C4 with the Phison 16GB mSATA.
Zero issues.

My plan:

Get a quality tiny USB 3.0 pen drive like
Do a custom install, mount /var and /tmp to the USB drive. This should store all logs, Squid cache and write intensive stuff to the USB sparing precious write cycles on the SSD. Now you can cache, log and graph to your hearts content.

Aug 16th is the release date.

I was excited about this card /w SFP for WAN and spoke to their support, but the specs seem off and they weren't forthcoming with answers. In fact, tech support which was apparently forwarded my emails never got back to me.
They were more interested in me not buying it from the UK and having a mate carry it down, and instead source a local supplier, guess what Draytek, if there there was one, I would. Oh, and how many pieces did I want to buy, fair enough.

This is what I asked:

Could you guys post some (specs), as it seems unlikely that a card capable of VDSL/SFP speeds will max out at 150Mb/s even without hardware accelerated NAT?

I would kill for a mini-PCI or an external Ethernet based ADSL/VDSL card. There's a large enough market, but not large enough for the quantities required to bring prices down in China.
The guys who make the Turris Omnia router have explored cheaper Chinese chipsets and they don't have the required VDSL performance. Sadly this appears like one of the first real choices for integration and we don't have any real specs yet.