Messages

1

Hardware and Performance / Re: OpnSense on Sophos SG series

« on: March 04, 2020, 01:02:17 am »

New update: v20.1 is running just fine on my Sophos SG 115 (for about 20 days now).

2

20.1 Production Series / Re: 1:1 NAT with an IPsec tunnel (in a multi-WAN setup)

« on: February 25, 2020, 01:03:43 pm »

Adding a firewall rule on LAN interface configured as follow did the trick: from=LAN_net to=172.31.254.254/32 gateway=default
(and placed before my firewall rule that sets gateway to the "primary/failover" gateway group for all traffic)

A tcpdump -n -i enc0 still don't show translation for outgoing traffic (id. 10.33.0.1) but answer arrives for translated address (id. 10.88.0.1):

12:39:44.593119 (authentic,confidential): SPI 0xbde8b870: IP 10.33.0.1 > 172.31.254.254: ICMP echo request, id 60353, seq 18, length 64
12:39:44.593503 (authentic,confidential): SPI 0xbde8b870: IP 172.31.254.254 > 10.88.0.1: ICMP echo reply, id 60353, seq 18, length 64

In the web GUI, at "Firewall: Log Files: Live View", I do have translation for outgoing traffic (id. 10.88.0.1):

Code: [Select]

IPsec Feb 25 12:39:44 10.88.0.1 172.31.254.254 icmp IPsec internal host to host
lan Feb 25 12:39:44 10.88.0.1 172.31.254.254 icmp Allow access to third-party server behind IPsec tunnel
So, to summarize, I needed (on my side):

• A firewall rule on all WAN interfaces to allow ESP ISAKMP and IPsec NAT-T (see guide)
• IPsec tunnel with "Apply Policy" on Phase 1 and Phase 2 where local network="10.88.0.0/16", remote network="172.31.254.254/32" and Manual SPD entry=10.33.0.0/16
• A NAT "One-to-One" rule where type=BINAT, external network="10.88.0.0/16", source network="10.33.0.0/16" and destination network="172.31.254.254/32"
• A firewall rule on LAN interface where source="LAN_net:*", direction="in", destination="172.31.254.254/32:*", gateway="default"
• A firewall rule on IPsec interface where source="172.31.254.254/32:*", direction="in", destination="LAN_net:*", gateway="default"

Guides :

• Setup IPsec site to site tunnel
• IPSec BINAT

3

20.1 Production Series / Re: 1:1 NAT with an IPsec tunnel

« on: February 24, 2020, 05:23:45 pm »

Just a thought: could my multi-wan setup (primary with failover) be responsible for the LAN clients' traffic not going through the tunnel?

4

20.1 Production Series / Re: 1:1 NAT with an IPsec tunnel

« on: February 24, 2020, 03:27:11 pm »

Also, if my LAN clients ping or traceroute the IP 172.31.254.254 it goes out to WAN not via IPsec tunnel (tcpdump -n -i enc0).
I don't understand why a ping to the same IP would follow different path if executed from OPNsense with LAN interface as source or executed from a computer on LAN (having the OPNsense as default gateway).

I naively tried to add a "Firewall: NAT: Outbound" rule on IPsec interface to replace traffic from 10.33.0.0/16 (LAN) to 172.31.254.254 (third party server) by 10.88.0.0/16 (natted network) with no luck.

5

20.1 Production Series / Re: 1:1 NAT with an IPsec tunnel

« on: February 24, 2020, 01:32:39 pm »

Using a tcpdump -n -i enc0 I can see my ping -s 10.33.0.1 172.31.254.254 (executed from OPNsense, whose LAN's address is "10.33.0.1") but I get no ping response and tcpdump ouput show no translation:

13:12:13.844882 (authentic,confidential): SPI 0xd0fb1d32: IP 10.33.0.1 > 172.31.254.254: ICMP echo request, id 31860, seq 0, length 64

(One of) The other thread I've found (« Updated IPSec with BiNAT walk-through needed? ») seems to leave Manual SPD field blank and use a "type=BINAT dest=any" NAT 1:1 rule which did not matched documentation, but it was 2 years ago.

Is there a way to show/debug SPD entries?

6

20.1 Production Series / Re: 1:1 NAT with an IPsec tunnel

« on: February 24, 2020, 11:44:17 am »

Thank for the pointer: In the mean time I tried to add my LAN as manual SPD entry but I saw no change of behavior.

Does BINAT setup requires to add specific firewall rule related to the natted network 10.88.0.0/16? The BINAT guide does not say anything about it but the IPsec site-to-site tunnel guide asks to create a "action=pass from=*:* to=LAN_net:*" rule on IPsec interface (which I did).
So I wonder if I need to create another rule (eg. to allow traffic from LAN to 10.88.0.0/16).

7

French - Français / Re: Router le trafic de mon VLAN guest sur un autre WAN que mon VLAN 1

« on: February 23, 2020, 09:27:31 pm »

Pourquoi ne pas utiliser une règle de pare-feu (dans "Firewall: Rules: LAN_Guests") qui définit la passerelle à utiliser ?

• Interface: LAN_Guests
• Source (address:port): LAN_Guest network:*
• Destination (address:port): *:*
• Gateway: GW_ADSL

Où "LAN_Guests" correspond à "igbX_vlanY"

?

8

20.1 Production Series / Re: 1:1 NAT with an IPsec tunnel

« on: February 23, 2020, 08:04:56 pm »

Forgot to say I followed "Setup IPsec site to site tunnel" guide (https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html), added an "allow any to any" firewall rule on IPsec interface and allowed ESP, ISAKMP, IPsec NAT-T protocols on WAN interface.

9

20.1 Production Series / [SOLVED] 1:1 NAT with an IPsec tunnel (in a multi-WAN setup)

« on: February 23, 2020, 07:47:06 pm »

Hello,

I fail to configure 1:1 NAT for trafic going via an IPsec tunnel (tunnel between my LAN and the network of a third party)

Here is the context :

My LAN network IP address is : 10.33.0.0/16
Third party IP address of the server I need to access via IPsec tunnel : 172.31.254.254/32
Network arriving in the tunnel (for 1:1 NAT) : 10.88.0.0/16

I am using OPNsense version 20.1.1.

Here is the IPsec configuration (algorithms part taken out) :

• Phase 1 :
        
  • Key Exchange version : V1
  • Interface : WAN
  • Remote gateway : 5.5.5.5 (Third party server IP)
  • Authentication method : Mutual PSK
  • My identifier : 3.3.3.3 (my public IP)
  • Peer identifier : 5.5.5.5
  • Install policy : (Checked)
  • Tunnel Isolation : (Unchecked)
  • NAT Traversal : Enable
     
• Phase 2 :
        
  • Mode : Tunnel IPv4
  • Local Network :
                
    • Type : Network
    • Address : 10.88.0.0/16
             
  • Remote Network :
                
    • Type : Address
    • Address : 172.31.254.254/32
             
  • Manual SPD entries : (Empty)
     

And here is the the 1:1 NAT configuration :

• Interface : IPsec
• Type : BINAT
• External network : 10.88.0.0/16
• Source / invert : (Unchecked)
• Source :
        
  • Type : Single host or Network
  • Address : 10.33.0.0/16
     
• Destination / invert : (Unchecked)
• Destination : any
• NAT reflection : Use system default

I do have an "IPsec" entry in the "Firewall: Rules" part of the GUI but nowhere else (not in "Interfaces" nor when trying to add a gateway or a route).

IPsec tunnel seems UP (according to the OPNsense dashboard) but I can't ping 172.31.254.254 or something in 10.88.0.0 from LAN.
And I don't see how it could work because netstat -rn shows no entry for 172.31.254.254 nor 10.88.0.0.

Do I need to add my LAN address (10.33.0.0/16) to Phase 2's "Manual SPD entries" ?
Where/How could I see thoses "SPD entries" ?

Thank you.

10

Hardware and Performance / Re: OpnSense on Sophos SG series

« on: February 14, 2020, 11:48:44 am »

Just an update: My Sophos SG 115 ran fine on various OPNsense versions since my last post on this topic :

• 18.7
• 19.1
• 19.7 (current: 19.7.10_1)

20.1 is yet to test.

11

18.7 Legacy Series / Benchmark each WAN bandwidth on multi-WAN setup ?

« on: January 16, 2019, 02:27:50 pm »

Hello,

To periodically benchmark the bandwidth of my WAN connection I use speedtest-cli: which works fine.
But I want to extend this benchmark to the other WANs (I have a multi-WAN failover setup) so I guess I need a firewall rule with gateway policy to force traffic to go via the other WAN.

Say the computer running speedtest-cli has IP 192.168.0.100, I can add a OPNsense firewall rule "from=192.168.0.100; gw=WAN_FAILOVER" but I don't want enable/disable the rule each time... so I am looking for a way to make this permanent/stable.

I see 3 ways:

• Add virtual network interface (eg. eth0:1, eth0:2, ...) to the computer running speedtest-cli (with dedicated LAN IP address 192.168.0.x) for each WAN to benchmark (WAN_PRIMARY, WAN_FAILOVER) and add a OPNsense firewall rules for each WAN:
  
  • from=192.168.0.101; gw=WAN_PRIMARY
  • from=192.168.0.102; gw=WAN_FAILOVER
• Choose a remote speedtest server (get the list with speedtest-cli --list) for each WAN to benchmark (WAN_PRIMARY, WAN_FAILOVER) and add a OPNsense firewall rule per speedtest server (destination) IP address:
  
  • from=192.168.0.100; to=SpeedTestA; gw=WAN_PRIMARY
  • from=192.168.0.100; to=SpeedTestB; gw=WAN_FAILOVER
• Add one virtual network interface (eg. eth0:1) to the computer running speedtest-cli (with dedicated LAN IP address 192.168.0.101). This IP will be exclusively used by the computer for benchmark. Add a OPNsense firewall rule "from=192.168.0.101; gw=WAN_PRIMARY"  and use the OPNsense API to update (change gateway) and enable/disable the firewall from computer running speedtest-cli.

I think solution 1 (virtual network interface) is the best but I am open to other solutions I have not thought about

12

18.1 Legacy Series / Re: Routing table not used for LAN clients (eg. for remote OpenVPN site)

« on: July 31, 2018, 12:14:22 pm »

Got it working, it was effectively a failing alias (see https://github.com/opnsense/core/issues/2590).
I managed to make it populated correctly and now it works.

Thanks for you help JasMan: I wouldn't have looked into this direction without it.

13

18.1 Legacy Series / Re: Routing table not used for LAN clients (eg. for remote OpenVPN site)

« on: July 30, 2018, 07:16:02 pm »

I think I found out the root cause: It might be because of some bug with firewall aliases in OPNsense: an alias fails to be completely expanded (it's an network alias where members are also network aliases), thus the firewall rule that should tell OPNsense to use "gw=default" for this destination does not match and it's then the final "gw=multiwan_gateway_group" that matches, ignoring my routing table.

14

18.1 Legacy Series / Re: Routing table not used for LAN clients (eg. for remote OpenVPN site)

« on: July 30, 2018, 06:45:03 pm »

First, let me thank you for the time you take to help me sort this out: much appreciated.

• The traceroute from OPNsense_Site1 to some IP of LAN_Site3 fails (including to OPNsense_Site3's LAN_Site3 IP):
  traceroute to 192.168.3.9 (192.168.3.9) from 192.168.1.254, 8 hops max, 40 byte packets
   1  80.10.10.9  0.396 ms  0.342 ms  0.278 ms
   2  * * *
   3  * * *
  [...]
  I didn't understand the "Runs it to the WAN interface as the traceroute from the clients?" test.
  
• The traceroute from OPNsense_Site1 to OpenVPN interface for LAN_Site3 (192.168.254.6) fails (same for IP 192.168.254.5 as destination):
  traceroute to 192.168.254.6 (192.168.254.6) from 192.168.1.254, 3 hops max, 40 byte packets
   1  80.10.10.9  0.491 ms  0.285 ms  0.259 ms
   2  * * *
   3  * * *
• You are right, in my first post I simplified the setup: I only took 2 tunnels (3 sites) as an example but when giving the full routing table I gave all 5 tunnels (and had some conflict on the IP indeed).
• In fact, I have already disabled multi-WAN load balancing: My OPNsense_Site1 LAN interface has a "src=* dest=* gw=gateway_group_of_only_one_gateway" final firewall rule
• I don't block traffic from LAN_2 to LAN_3.
  I tested and a ping from LAN_3 to LAN_2 works (tested with ping on one side and tcpdump on the other), but a traceroute fails (no capture by tcpdump) and have LAN_3's gateway as first hop.
  But a ping from LAN_2 to LAN_3 fails: ping fails and tcpdump captures nothing.
  So: that made me think... and I noticed I had a "allow IPv4 ICMP" rule on OPNsense_Site3 but not on OPNsense_Site2 (nor OPNsense_Site1), once enabled ping works in both ways.
  I thought traceroute used ICMP.
• As all my sites uses multi-WAN (with failover), the last firewall rule of LAN interface are: action=pass, proto=*, src=LAN, dst=*, gw=gateway_group_with_one_primary_gw_and_one_failover_gw
  So yes, firewall always defines a "policy based routing".

Theses last 3 questions/tests of yours were very pertinent, first I had a misconfiguration that allowed ping in one direction but not the other. And I had also forgot about the "policy based routing".
Still I don't understand yet why it worked with some network/tunnel and not the other: it must be some underlying misconfiguration that never popped visible issue until now.

I'm digging the firewall "policy based routing" rule issue lead now

15

18.1 Legacy Series / Re: Routing table not used for LAN clients (eg. for remote OpenVPN site)

« on: July 28, 2018, 12:42:21 am »

I wonder if what franco said here:

Maybe this is due to anti-spoof, or maybe due to a forced catch-all gateway multi-wan rule that slurps your local traffic and pushes it to the gateway on said interface.

The latter is more likely, but there was no statement about it in the OP.

Could explain the fact that some networks are getting out via my gateway. Or maybe this network address is known to my Internet provider and somehow the gateway and OPNsense shared this information via some route table sharing protocol (which I didn't enabled and could not find any settings, though).

I do have multi-WAN enabled on this OPNsense box but don't have any specific rule that could explain why if fails specifically with 192.168.3.x.