Messages

1

Hardware and Performance / Re: USB 2.5Gb adaptor, ProxMox Install

« on: June 13, 2024, 03:48:11 pm »

I'm wondering if this is a driver issue? I switched things up, letting Proxmox handle the adaptors, and just sharing them with the VM using a Linux Bridge and VirtIO, rather than using USB passthrough, and iperf now shows full speed. So I guess that's a solution, though OPNSense showing the interfaces as always up and 10Mbps bugs my sensibilities (and may cause issues with things like High Availability if the interface is really down?). I am under the impression this is "normal" for VirtIO devices, however.

2

Hardware and Performance / USB 2.5Gb adaptor, ProxMox Install

« on: June 12, 2024, 07:16:38 pm »

I have a backup OPNSense install running under ProxMox installed on an intel Mac Mini (I don't know the exact model, but I can try to dig it up if it matters). OPNSense is fully updated as of this morning, running version 24.1.8-amd64.

To this hardware I added a 2.5Gbe USB adaptor, And set it up in ProxMox to do USB passthrough to the VM. From the OPNSense command line it now shows up like this in usbconfig:

Code: [Select]

root@gatekeeper2:~ # usbconfig -d 1.2 dump_device_desc
ugen1.2: <Realtek USB 10/100/1G/2.5G LAN> at usbus1, cfg=1 md=HOST spd=SUPER (5.0Gbps) pwr=ON (64mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0320
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0009
  idVendor = 0x0bda
  idProduct = 0x8156
  bcdDevice = 0x3104
  iManufacturer = 0x0001  <Realtek>
  iProduct = 0x0002  <USB 10/100/1G/2.5G LAN>
  iSerialNumber = 0x0006  <4013000000>
  bNumConfigurations = 0x0003


ifconfig for the interface shows the following:

Code: [Select]

ue0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN (lan)
options=80008<VLAN_MTU,LINKSTATE>
ether 8c:ae:4c:dd:d5:9e
inet6 fe80::8eae:4cff:fedd:d59e%ue0 prefixlen 64 scopeid 0x6
inet 10.27.81.247 netmask 0xffffff00 broadcast 10.27.81.255
inet 10.27.81.1 netmask 0xffffff00 broadcast 10.27.81.255 vhid 3
carp: BACKUP vhid 3 advbase 1 advskew 100
media: Ethernet autoselect
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

At any rate, I set that up as my LAN interface, and used iperf to run a test back to my main router (connected via a 10G link). Somewhat to my surprise, I saw I was only getting 100Mbps. After some digging, I found this: https://forum.opnsense.org/index.php?topic=27189.0, which suggested "setting the device into ECM mode". I tried that, which did help - I now get around 500Mbps.

Am I missing something/doing something wrong here? Looking at ifconfig, I would think it should show the media type - for example, one interface on my main router shows this for media:

Code: [Select]

media: Ethernet autoselect (10Gbase-Twinax <full-duplex,rxpause,txpause>)
But on the backup it's just "Ethernet autoselect" - no indication of what it selected. Also, the "SIMPLEX" bugs me (shouldn't it be "DUPLEX" or just not there?), but that's the same on my main OPNsense router (which is running bare metal on an old Intel i7), as well as my desktop Mac Studio (though settings shows full-duplex. Gah!), so maybe that's normal?

3

General Discussion / Re: VLAN configuration clarification

« on: February 07, 2024, 07:05:02 pm »

Because as soon as an untagged port is a bridge member you cannot use that port for VLANs. Simply not possible. That's a constraint of the FreeBSD network stack. And that's because ... you guessed it ... FreeBSD is not a switch.

HTH,
Patrick

Interesting. Because em0 and em1 are bridge members in my configuration - and I was able to put em1 as the parent for the VLAN without issue, and it works.

Regardless, your point about OPNSense not being a switch is well taken. It sounds like I should find something else to do with that second physical port rather than trying to make it available as another LAN port - even if my CPU can handle the load without breaking a sweat, the system simply isn't designed for the use case I am envisioning.

Thanks for the information!

4

General Discussion / Re: VLAN configuration clarification

« on: February 07, 2024, 06:15:10 pm »

A VLAN cannot be on either port - well it can, but the concept is to designate specific ports to carry tagged frames, so called trunk ports, and to designate other ports to carry untagged frames, so called access ports.

Ok, so what/which am I doing when I create a VLAN with a parent of em1? Clearly my understanding of this concept was more lacking than I thought... 

EDIT: After thinking about this some more, my thinking is that creating a VLAN with a parent of em1 is turning em1 into a trunk port - correct? If so, then the question is how do I *also* turn em0 into a trunk port for the same VLAN, such that the DHCP server, etc, is available on that VLAN on both physical ports?

Why would you ever want to move the connection to the switch from em0 to em1 or vice versa?

Why wouldn't I? The point of having two LAN ports in a bridged configuration is that they are interchangeable, and I don't have to worry about what is plugged into what - it's essentially just a two-port switch. Or what if I add another switch/access point on em0 and want to put some Guest network devices on that one as well, such that there are guest network devices on both ports?

The advice about the managed switch still holds - only managed switches feature trunk ports and tagged frames.

Sure, and I'm not saying it's not good advice - I'm just saying I don't understand how it helps in this situation, where the wireless router is sending both tagged and untagged traffic on the same port.

In case it wasn't clear, the goal is to have a Guest network/VLAN available on the LAN with its own DHCP server, isolated traffic, perhaps a captive portal, etc, such that any traffic tagged with that VLAN id is isolated to the Guest network. This is working as desired with my current setup - as long as the traffic comes in over em1. What I'm not clear on is if it would still work if the VLAN traffic was coming in on em0, given that the parent device for the VLAN is em1.

5

General Discussion / Re: VLAN configuration clarification

« on: February 07, 2024, 03:38:27 pm »

I'm sorry, but I'm still confused how this would help. For one thing, I don't want all wireless traffic to be tagged for the VLAN - wouldn't setting a port on the switch to the VLAN tag all traffic on that port? For another, I am still unclear as to how this would solve anything should the switch be connected to em0 rather than em1 - OPNSense would still need to know that the VLAN could be on either em0 or em1, right?

Sorry, I am clearly missing something here...

6

General Discussion / Re: VLAN configuration clarification

« on: February 06, 2024, 06:05:11 pm »

My apologies for being dense here, but I'm not clear on how that would solve the main issue I have with the current configuration, that being what happens if I plug the wireless router (or the switch it is on) into em0 instead of em1? Since those are both LAN ports, I would like to be able to plug into either one of them arbitrarily and have the behavior remain unchanged.

That said, I am also struggling a bit with a couple of other points relating top your response:

1) What do you mean by "join the OPNsense em1 port to the same VLAN as untagged"? Isn't that the default, i.e. no VLAN?
2) The switch in question is unmanaged, so I can't set a specific port to a specific VLAN. I guess I didn't mention that, sorry!
3) Even if I could, I don't want *all* traffic from my wireless routers tagged as VLAN 20, only the guest traffic. This is the way they are currently working with the wireless router doing the tagging.

Reading over my original post yet again, I see that I may have led to some confusion by not mentioning that the guest network is NOT isolated on port em1. In fact, currently all my LAN devices are physically connected through em1. The Guest traffic is simply a small portion of the traffic flowing through that port, identified by the VLAN tag applied by the wireless router when a client connects to the guest SSID rather than the main SSID.

Sorry for any confusion created by not mentioning this to begin with!

7

General Discussion / VLAN configuration clarification

« on: February 05, 2024, 08:05:39 pm »

Technically I have this working, but the configuration doesn't feel right to me, so I'm hoping someone can provide clarification.

Running OpnSense 23.7.10 on an intel Core i7-3770 3.4 with 24GB RAM.

For the LAN, I have two physical ports: em0 and em1. These are set up as members of a bridge (bridge1), which is then assigned to the LAN interface.

My wireless router is physically connected via a switch to em1. The wireless router creates a guest network, which is vlan tagged as VLAN 20 (I have no control over this, I can only turn the guest network on or off and assign a SSID).

In order to separate out the guest network traffic, I created a vlan 20 interface in the OPNsense box, assigned it a parent of em1, created a DHCP server for it, put in firewall rules to prevent traffic from the VLAN from reaching my internal network, etc.

As I said at the start, this all works, but my main concern is having em1 as the parent for the VLAN. Is that correct/kosher? What happens if I move the wireless to em0 at some point? My first thought was that the bridge should be the parent for the VLAN, but that isn't even an option, and may not even make sense. Then I was thinking maybe I should have a loopback interface be the parent, and add the VLAN as a member of the bridge, but I'm not sure about that either.

Do I have this set up correctly after all? Or is there a better way?

EDIT:

Just saw this thread: https://forum.opnsense.org/index.php?topic=38562.0 which suggests setting up the VLAN twice, once for each physical port, and then creating a bridge containing the two VLANs. Unfortunately that doesn't seem to work: I got DHCP well enough with that setup, but no traffic was passed on the bridge interface. I guess I might have missed something, but at the end of the day all I did was change the device for the interface from the single VLAN device to the bridge device, so it seems like the settings should have all been tied to the interface, not the VLAN device. Dunno. Maybe I'll try this configuration again in a couple of days.

8

Virtual private networks / Re: IPSec VPN seems to work, but no communication?

« on: November 02, 2023, 04:14:25 pm »

GOT IT!!!!! Well, for OpenVPN at least. Apparently OpenVPN didn't like me using the letsencrypt.org certificate for the server, but the self-generated certificate for the client. I switched over to using the self-generated certificate for the server, and got a connection - and it even routes traffic correctly!

So not the IPsec connection I was going for, but it works, so I guess that's solved?

Thanks everyone who helped me troubleshoot this!

9

Virtual private networks / Re: IPSec VPN seems to work, but no communication?

« on: November 02, 2023, 03:44:41 pm »

Did you also create and configure one for the server?

Yeah - I have the server set up with the ACME client, getting a certificate from letsencrypt.org. Though I also set up the local authority (which is how I created the user certificate), and have a server certificate created using that.

I used the official letsencrypt.org certificate for the OpenVPN server.

For what it's worth, I have a dynamic IP address with a dynamic DNS service on OPNsense set up through freedns, and I *can* connect (via port forwarding) to an OpenVPN Access Server instance I set up on a box behind the firewall, so I know OpenVPN works from my client machine to my host network in general, I just need to get all the settings right.

And yes, I did make sure to disable the port forward to that box before trying to set up OpenVPN on the OPNsense box 

I may try looking at the configuration file that box creates, vs the one OPNsense is giving me to see if I can figure out what's different between the two. Not sure if that's worth the effort or not.

10

Virtual private networks / Re: IPSec VPN seems to work, but no communication?

« on: November 02, 2023, 12:32:26 am »

OpenVPN mandates using certificates.

Well, I tried that too (that is, I created a certificate for my user and installed that on the client), still got the same error. So dunno

11

Virtual private networks / Re: IPSec VPN seems to work, but no communication?

« on: November 02, 2023, 12:23:01 am »

aaaand OpenVPN doesn't like me either. Every connection attempt just fails with "Peer certificate verification failure". I don't even want to *use* peer certificates! I just want to be able to log into my home network with a username and password!

Sigh. On to Wireguard I guess...

12

Virtual private networks / Re: IPSec VPN seems to work, but no communication?

« on: November 01, 2023, 06:41:04 pm »

For IPsec I'm using NCP client on macOS productively with my customers. Wireguard works also great, but not using that as customer remote access.

Yeah, I was hoping to avoid having yet another piece of software to install/manage on my client, but if the built-in VPN isn't functional, then so be it. Though I would prefer to go with something free (such as OpenVPN or Wireguard) if I can make it work, rather than paying for an IPsec client

13

Virtual private networks / Re: IPSec VPN seems to work, but no communication?

« on: November 01, 2023, 05:34:24 pm »

Given what I am seeing above, I'm beginning to think it's an issue with the built-in VPN client on MacOS Sonoma, not something wrong with my configuration, and as such I may have to throw in the towel and go with something else, like OpenVPN. 

14

Virtual private networks / Re: IPSec VPN seems to work, but no communication?

« on: November 01, 2023, 05:21:09 pm »

Thanks for those tips. This...makes no sense to me. the TCP dumps seems to show both the request and reply flowing smoothly, both through my router and through the local hosts I am pinging (see below). It is just the remote host that doesn't seem to be getting the memo. Perhaps interestingly (perhaps expectedly) running a `tcpdump -i any proto ICMP -n` on the remote host shows nothing whatsoever.

Do you see anything I am missing here? Because to me it looks like it should be working...

Latest log attached in zip form so it will be small enough for an attachment, rest of the commands below (hopefully in a readable format)

Remote host IP: 137.229.32.97
Local host IP: 10.27.81.60

Code: [Select]

pfctl -s rules

scrub on em0 all fragment reassemble
scrub on em1 all fragment reassemble
block drop in log on ! em0 inet from 10.27.81.0/24 to any
block drop in log inet from 10.27.81.1 to any
block drop in log on ! em1 inet from 69.178.80.0/20 to any
block drop in log inet from 69.178.88.174 to any
block drop in log on em0 inet6 from fe80::222:4dff:fe9d:7b76 to any
block drop in log on em1 inet6 from fe80::222:4dff:fe9d:7b72 to any
block drop in log inet all label "02f4bab031b57d1e30553ce08e0ec131"
block drop in log inet6 all label "02f4bab031b57d1e30553ce08e0ec131"
pass in log quick inet6 proto ipv6-icmp all icmp6-type unreach keep state label "1d245529367b2e34eeaff16086aeafe9"
pass in log quick inet6 proto ipv6-icmp all icmp6-type toobig keep state label "1d245529367b2e34eeaff16086aeafe9"
pass in log quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state label "1d245529367b2e34eeaff16086aeafe9"
pass in log quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state label "1d245529367b2e34eeaff16086aeafe9"
pass out log quick inet6 proto ipv6-icmp from (self) to fe80::/10 icmp6-type echoreq keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
pass out log quick inet6 proto ipv6-icmp from (self) to ff02::/16 icmp6-type echoreq keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
pass out log quick inet6 proto ipv6-icmp from (self) to fe80::/10 icmp6-type echorep keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
pass out log quick inet6 proto ipv6-icmp from (self) to ff02::/16 icmp6-type echorep keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
pass out log quick inet6 proto ipv6-icmp from (self) to fe80::/10 icmp6-type routersol keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
pass out log quick inet6 proto ipv6-icmp from (self) to ff02::/16 icmp6-type routersol keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
pass out log quick inet6 proto ipv6-icmp from (self) to fe80::/10 icmp6-type routeradv keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
pass out log quick inet6 proto ipv6-icmp from (self) to ff02::/16 icmp6-type routeradv keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
pass out log quick inet6 proto ipv6-icmp from (self) to fe80::/10 icmp6-type neighbrsol keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
pass out log quick inet6 proto ipv6-icmp from (self) to ff02::/16 icmp6-type neighbrsol keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
pass out log quick inet6 proto ipv6-icmp from (self) to fe80::/10 icmp6-type neighbradv keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
pass out log quick inet6 proto ipv6-icmp from (self) to ff02::/16 icmp6-type neighbradv keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echoreq keep state label "42e9d787749713a849d8e92432efdfaa"
pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echoreq keep state label "42e9d787749713a849d8e92432efdfaa"
pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state label "42e9d787749713a849d8e92432efdfaa"
pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state label "42e9d787749713a849d8e92432efdfaa"
pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state label "42e9d787749713a849d8e92432efdfaa"
pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state label "42e9d787749713a849d8e92432efdfaa"
pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbrsol keep state label "42e9d787749713a849d8e92432efdfaa"
pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbrsol keep state label "42e9d787749713a849d8e92432efdfaa"
pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbradv keep state label "42e9d787749713a849d8e92432efdfaa"
pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbradv keep state label "42e9d787749713a849d8e92432efdfaa"
pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type echoreq keep state label "8752fca75c6be992847ea984161bd3f1"
pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routersol keep state label "8752fca75c6be992847ea984161bd3f1"
pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routeradv keep state label "8752fca75c6be992847ea984161bd3f1"
pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbrsol keep state label "8752fca75c6be992847ea984161bd3f1"
pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbradv keep state label "8752fca75c6be992847ea984161bd3f1"
pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type echoreq keep state label "71dd196398b3f1da265dbd9dcad00e70"
pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type routersol keep state label "71dd196398b3f1da265dbd9dcad00e70"
pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type routeradv keep state label "71dd196398b3f1da265dbd9dcad00e70"
pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type neighbrsol keep state label "71dd196398b3f1da265dbd9dcad00e70"
pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type neighbradv keep state label "71dd196398b3f1da265dbd9dcad00e70"
block drop in log quick inet proto tcp from any port = 0 to any label "7b5bdc64d7ae74be1932f6764a591da5"
block drop in log quick inet proto udp from any port = 0 to any label "7b5bdc64d7ae74be1932f6764a591da5"
block drop in log quick inet6 proto tcp from any port = 0 to any label "7b5bdc64d7ae74be1932f6764a591da5"
block drop in log quick inet6 proto udp from any port = 0 to any label "7b5bdc64d7ae74be1932f6764a591da5"
block drop in log quick inet proto tcp from any to any port = 0 label "ae69f581dc429e3484a65f8ecd63baa5"
block drop in log quick inet proto udp from any to any port = 0 label "ae69f581dc429e3484a65f8ecd63baa5"
block drop in log quick inet6 proto tcp from any to any port = 0 label "ae69f581dc429e3484a65f8ecd63baa5"
block drop in log quick inet6 proto udp from any to any port = 0 label "ae69f581dc429e3484a65f8ecd63baa5"
pass log quick inet6 proto carp from any to ff02::12 keep state label "cf439d72ef4d245e8ad4a1405df1f665"
pass log quick inet proto carp from any to 224.0.0.18 keep state label "2ffa978d51f7b3fbc9000c2895106ee7"
block drop in log quick proto tcp from <sshlockout> to (self) port = ssh label "669143f420c3ab4118bcb0bf4b5fd823"
block drop in log quick proto tcp from <sshlockout> to (self) port = https label "6baefc2a9cf2536834c092a51134a45c"
block drop in log quick from <virusprot> to any label "8e367e2f9944d93137ae56d788c5d5e1"
pass in log quick on em0 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "5168be2cca1e130b1ef2ac18161356a8"
pass in log quick on em0 proto udp from any port = bootpc to (self) port = bootps keep state label "0b032d1bab91fc97e4a7faf03a7f17c3"
pass out log quick on em0 proto udp from (self) port = bootps to any port = bootpc keep state label "5039e43005a9aa50eb032af274cc9aad"
pass in log quick on em0 inet6 proto udp from fe80::/10 to fe80::/10 port = dhcpv6-client keep state label "fef3d333d96a8d3558956de1fffc61cc"
pass in log quick on em0 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-client keep state label "fef3d333d96a8d3558956de1fffc61cc"
pass in log quick on em0 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-server keep state label "d2bd536587a9f5680c1f850b2d346839"
pass in log quick on em0 inet6 proto udp from ff02::/16 to fe80::/10 port = dhcpv6-server keep state label "3420206ced96c01ef73fbc4ac9deb745"
pass in log quick on em0 inet6 proto udp from fe80::/10 to (self) port = dhcpv6-client keep state label "0fd202708c326aebbe44ab710b6d3652"
pass out log quick on em0 inet6 proto udp from (self) port = dhcpv6-server to fe80::/10 keep state label "83f6c28de8efae9b444094e4a5bf898c"
pass in log quick on em1 inet6 proto udp from fe80::/10 port = dhcpv6-client to fe80::/10 port = dhcpv6-client keep state label "a6cd2cce1bc1d912f6258ef1f3fb07e1"
pass in log quick on em1 proto udp from any port = dhcpv6-server to any port = dhcpv6-client keep state label "f7e4334c3e7dc4ba900c5780b828d4a3"
pass out log quick on em1 proto udp from any port = dhcpv6-client to any port = dhcpv6-server keep state label "5ba1258fcaf073eff4060b40ff63044d"
pass in log quick on em1 proto udp from any port = bootps to any port = bootpc keep state label "f994f615e00b8be0042263f86c79913f"
pass out log quick on em1 proto udp from any port = bootpc to any port = bootps keep state label "5cf7ab808da1fcbca1ddb9ba9b46b669"
block drop in log quick on em1 inet from <bogons> to any label "b7cd97a164650b538506fb551a0369e7"
block drop in log quick on em1 inet6 from <bogonsv6> to any label "f140a48ddade668b9d6f5259669a1d5c"
pass in quick on lo0 all no state label "7535c94082e72e2207679aadb26afd92"
pass out log all flags S/SA keep state allow-opts label "fae559338f65e11c53669fc3642c93c2"
pass out log on enc0 all flags S/SA keep state label "c1eff64cbafdd6b80448f92cd4aff7e5"
pass in log quick on em0 proto tcp from any to (self) port = ssh flags S/SA keep state label "bb72618316fdf630cdf15f33ae3d699f"
pass in log quick on em0 proto tcp from any to (self) port = http flags S/SA keep state label "bb72618316fdf630cdf15f33ae3d699f"
pass in log quick on em0 proto tcp from any to (self) port = https flags S/SA keep state label "bb72618316fdf630cdf15f33ae3d699f"
pass out log route-to (em1 69.178.80.1) inet from (em1) to ! (em1:network) flags S/SA keep state allow-opts label "ae4923441933901a90e7d9997f83b9f6"
pass in log quick on enc0 inet all flags S/SA keep state label "e3742b5a34e16197f4feafb15b3c6264"
pass in log quick on enc0 inet6 all flags S/SA keep state label "e3742b5a34e16197f4feafb15b3c6264"
pass in quick on openvpn inet all flags S/SA keep state label "f9bd0646952d6451270a554876a7fc2f"
pass in log quick on em1 reply-to (em1 69.178.80.1) inet proto esp from any to (em1) keep state label "21df42ed9a2f63199a7b34caf3b368ce"
pass in log quick on em1 inet6 proto esp from any to (em1) keep state label "21df42ed9a2f63199a7b34caf3b368ce"
pass in quick on em1 reply-to (em1 69.178.80.1) inet proto udp from any to (em1) port = isakmp keep state label "6db69ea380b5d3568fff18d9f2613591"
pass in quick on em1 reply-to (em1 69.178.80.1) inet proto udp from any to (em1) port = ipsec-nat-t keep state label "6db69ea380b5d3568fff18d9f2613591"
pass in quick on em1 inet6 proto udp from any to (em1) port = isakmp keep state label "6db69ea380b5d3568fff18d9f2613591"
pass in quick on em1 inet6 proto udp from any to (em1) port = ipsec-nat-t keep state label "6db69ea380b5d3568fff18d9f2613591"
pass in quick on em1 reply-to (em1 69.178.80.1) inet proto icmp from any to (em1) keep state label "814aa8aefcc1293a6d38e5fb227d4f66"
pass in quick on em1 inet6 proto ipv6-icmp from any to (em1) keep state label "814aa8aefcc1293a6d38e5fb227d4f66"
pass in quick on em1 reply-to (em1 69.178.80.1) inet proto tcp from any to 10.27.81.60 port = imaps flags S/SA keep state label "fe9c419bba801dc8ae9171b46d403a70"
pass in quick on em1 reply-to (em1 69.178.80.1) inet proto tcp from any to 10.27.81.60 port = http flags S/SA keep state label "639d2f3b29418248181069c17215d193"
pass in quick on em1 reply-to (em1 69.178.80.1) inet proto tcp from any to 10.27.81.60 port = smtp flags S/SA keep state label "c8715002cd9f2473b9d5b2a6f1bd932a"
pass in quick on em1 reply-to (em1 69.178.80.1) inet proto tcp from any to 10.27.81.60 port = imap flags S/SA keep state label "95c26eef2e3e4b10ab24410b49607a7f"
pass in quick on em1 reply-to (em1 69.178.80.1) inet proto tcp from any to 10.27.81.60 port = smtps flags S/SA keep state label "f567acd4ea8dd59eee904a15e2179395"
pass in quick on em1 reply-to (em1 69.178.80.1) inet proto udp from any to 10.27.81.60 port = openvpn keep state label "4ba2235140039a651483e748534ee3a1"
pass in quick on em1 reply-to (em1 69.178.80.1) inet proto tcp from any to 10.27.81.60 port = 943 flags S/SA keep state label "d972c26bcf562b5f300bf0eb8df65d02"
pass in log quick on em1 reply-to (em1 69.178.80.1) inet proto tcp from any to 10.27.81.60 port = https flags S/SA keep state label "d730ade7f168ca2b6f67ed20cf3f48bc"
pass in log quick on em0 inet proto tcp from any to 127.0.0.1 port = domain flags S/SA keep state label "47c04110e1336fa111ad5190bcd73b41"
pass in log quick on em0 inet proto udp from any to 127.0.0.1 port = domain keep state label "47c04110e1336fa111ad5190bcd73b41"
pass in quick on em0 inet from (em0:network) to any flags S/SA keep state label "4bbc875dd7dcb4ad450d0f9d0f91b692"
pass in quick on em0 inet6 from (em0:network) to any flags S/SA keep state label "133a07584c296ef77d9a309f604315ea"
pass in quick on em0 inet6 from fe80::/10 to any flags S/SA keep state label "133a07584c296ef77d9a309f604315ea"
pass out log on em1 proto udp from any to any port = isakmp keep state label "022363a8f0ee1cceef8d18eeef536433"
pass in log on em1 reply-to (em1 69.178.80.1) inet proto udp from any to any port = isakmp keep state label "3dd371c341d2544829ba5926b472378c"
pass out log on em1 proto udp from any to any port = ipsec-nat-t keep state label "bb9ef419eca4a7ddbcce91fc7054fc38"
pass in log on em1 reply-to (em1 69.178.80.1) inet proto udp from any to any port = ipsec-nat-t keep state label "b1a75ea5c4b603f2889008a64e2c1149"
pass out log on em1 proto esp all keep state label "a247580377c9b6716c340d6b4a471b55"
pass in log on em1 reply-to (em1 69.178.80.1) inet proto esp all keep state label "a4a2bf39bff388e10337dafeee3828e0"
anchor "acme-client/*" all


pfctl -s nat

no nat proto carp all
nat log on em1 inet from (em0:network) to any port = isakmp -> (em1:0) static-port
nat log on em1 inet from (lo0:network) to any port = isakmp -> (em1:0) static-port
nat log on em1 inet from 127.0.0.0/8 to any port = isakmp -> (em1:0) static-port
nat log on em1 inet from 10.27.84.0/24 to any port = isakmp -> (em1:0) static-port
nat log on em1 inet from (em0:network) to any -> (em1:0) port 1024:65535
nat log on em1 inet from (lo0:network) to any -> (em1:0) port 1024:65535
nat log on em1 inet from 127.0.0.0/8 to any -> (em1:0) port 1024:65535
nat log on em1 inet from 10.27.84.0/24 to any -> (em1:0) port 1024:65535
nat-anchor "acme-client/*" all
no rdr proto carp all
no rdr on em0 proto tcp from any to (em0) port = ssh
no rdr on em0 proto tcp from any to (em0) port = http
no rdr on em0 proto tcp from any to (em0) port = https
rdr on em1 inet proto tcp from any to (em1) port = http -> 10.27.81.60 port 80
rdr on em0 inet proto tcp from any to (em1) port = http -> 10.27.81.60 port 80
rdr on lo0 inet proto tcp from any to (em1) port = http -> 10.27.81.60 port 80
rdr log on em1 inet proto tcp from any to (em1) port = https -> 10.27.81.60 port 443
rdr on em1 inet proto tcp from any to (em1) port = smtp -> 10.27.81.60 port 25
rdr on em0 inet proto tcp from any to (em1) port = smtp -> 10.27.81.60 port 25
rdr on lo0 inet proto tcp from any to (em1) port = smtp -> 10.27.81.60 port 25
rdr on em1 inet proto tcp from any to (em1) port = imap -> 10.27.81.60 port 143
rdr on em0 inet proto tcp from any to (em1) port = imap -> 10.27.81.60 port 143
rdr on lo0 inet proto tcp from any to (em1) port = imap -> 10.27.81.60 port 143
rdr on em1 inet proto tcp from any to (em1) port = imaps -> 10.27.81.60 port 993
rdr on em1 inet proto tcp from any to (em1) port = smtps -> 10.27.81.60 port 465
rdr on em0 inet proto tcp from any to (em1) port = smtps -> 10.27.81.60 port 465
rdr on lo0 inet proto tcp from any to (em1) port = smtps -> 10.27.81.60 port 465
rdr on em1 inet proto udp from any to (em1) port = openvpn -> 10.27.81.60 port 1194
rdr on em1 inet proto tcp from any to (em1) port = 943 -> 10.27.81.60 port 943
rdr log on em0 inet proto tcp from any to ! (em0) port = domain -> 127.0.0.1 port 53
rdr log on em0 inet proto udp from any to ! (em0) port = domain -> 127.0.0.1 port 53
rdr-anchor "acme-client/*" all


Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            1-80-178-69.gci.ne UGS         em1
10.27.81.0/24      link#1             U           em0
gatekeeper         link#1             UHS         lo0
69.178.80.0/20     link#2             U           em1
174-88-178-69.gci. link#2             UHS         lo0
localhost          link#4             UH          lo0

Internet6:
Destination        Gateway            Flags     Netif Expire
localhost          link#4             UHS         lo0
fe80::%em0/64      link#1             U           em0
fe80::222:4dff:fe9 link#1             UHS         lo0
fe80::%em1/64      link#2             U           em1
fe80::222:4dff:fe9 link#2             UHS         lo0
fe80::%lo0/64      link#4             U           lo0
fe80::1%lo0        link#4             UHS         lo0


swanctl --list-sas

no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
con1: #15, ESTABLISHED, IKEv1, 7b75fd54d458c5f7_i 4be91184ab849282_r*
  local  'gatekeeper.brewstersoft.net' @ 69.178.88.174[500]
  remote '137.229.32.97' @ 137.229.32.97[500] XAuth: 'israel' [10.27.84.1]
  AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
  established 248s ago, rekeying in 13354s
  con1: #12, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96
    installed 247s ago, rekeying in 2751s, expires in 3353s
    in  c8b17443,   3208 bytes,    40 packets,     0s ago
    out 0334cb6e,   7352 bytes,    45 packets,     0s ago
    local  10.27.81.0/24
    remote 10.27.84.1/32
   
TCP Dump host on LAN (destination client) during ping:

root@watchman:~# tcpdump -i br0 proto ICMP -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:05:30.372294 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 3, length 64
08:05:30.372356 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 3, length 64
08:05:31.375614 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 4, length 64
08:05:31.375652 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 4, length 64
08:05:32.378598 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 5, length 64
08:05:32.378657 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 5, length 64
08:05:33.378304 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 6, length 64
08:05:33.378374 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 6, length 64
08:05:34.382842 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 7, length 64
08:05:34.382921 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 7, length 64
08:05:35.385426 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 8, length 64
08:05:35.385468 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 8, length 64
08:05:36.390296 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 9, length 64
08:05:36.390333 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 9, length 64
08:05:37.390469 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 10, length 64
08:05:37.390504 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 10, length 64
08:05:38.392235 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 11, length 64
08:05:38.392307 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 11, length 64
08:05:39.399218 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 12, length 64
08:05:39.399248 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 12, length 64
08:05:40.401661 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 13, length 64
08:05:40.401700 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 13, length 64
08:05:41.406685 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 14, length 64
08:05:41.406748 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 14, length 64

Firewall LAN interface:

root@gatekeeper:/home/israel # tcpdump -i em0 proto ICMP -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 262144 bytes
08:05:31.377214 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 4, length 64
08:05:31.377442 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 4, length 64
08:05:31.409149 IP 10.27.81.250 > 142.250.217.78: ICMP echo request, id 18156, seq 1, length 14
08:05:31.414584 IP 10.27.81.250 > 216.239.38.120: ICMP echo request, id 18155, seq 1, length 14
08:05:31.430467 IP 10.27.81.250 > 104.193.88.77: ICMP echo request, id 18157, seq 1, length 14
08:05:31.450488 IP 142.250.217.78 > 10.27.81.250: ICMP echo reply, id 18156, seq 1, length 14
08:05:31.457189 IP 216.239.38.120 > 10.27.81.250: ICMP echo reply, id 18155, seq 1, length 14
08:05:31.503578 IP 104.193.88.77 > 10.27.81.250: ICMP echo reply, id 18157, seq 1, length 14
08:05:31.669138 IP 10.27.81.251 > 104.193.88.123: ICMP echo request, id 22986, seq 1, length 14
08:05:31.671761 IP 10.27.81.251 > 142.250.217.110: ICMP echo request, id 22985, seq 1, length 14
08:05:31.677814 IP 10.27.81.251 > 216.239.38.120: ICMP echo request, id 22984, seq 1, length 14
08:05:31.720092 IP 142.250.217.110 > 10.27.81.251: ICMP echo reply, id 22985, seq 1, length 14
08:05:31.720110 IP 216.239.38.120 > 10.27.81.251: ICMP echo reply, id 22984, seq 1, length 14
08:05:31.741902 IP 104.193.88.123 > 10.27.81.251: ICMP echo reply, id 22986, seq 1, length 14
08:05:31.794959 IP 10.27.81.251 > 10.27.81.1: ICMP echo request, id 23157, seq 0, length 64
08:05:31.794986 IP 10.27.81.1 > 10.27.81.251: ICMP echo reply, id 23157, seq 0, length 64
08:05:32.380191 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 5, length 64
08:05:32.380364 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 5, length 64
08:05:32.409616 IP 10.27.81.250 > 142.250.217.78: ICMP echo request, id 18156, seq 2, length 14
08:05:32.414986 IP 10.27.81.250 > 216.239.38.120: ICMP echo request, id 18155, seq 2, length 14
08:05:32.430846 IP 10.27.81.250 > 104.193.88.77: ICMP echo request, id 18157, seq 2, length 14
08:05:32.451785 IP 142.250.217.78 > 10.27.81.250: ICMP echo reply, id 18156, seq 2, length 14
08:05:32.460504 IP 216.239.38.120 > 10.27.81.250: ICMP echo reply, id 18155, seq 2, length 14
08:05:32.502566 IP 104.193.88.77 > 10.27.81.250: ICMP echo reply, id 18157, seq 2, length 14
08:05:32.669463 IP 10.27.81.251 > 104.193.88.123: ICMP echo request, id 22986, seq 2, length 14
08:05:32.672046 IP 10.27.81.251 > 142.250.217.110: ICMP echo request, id 22985, seq 2, length 14
08:05:32.678109 IP 10.27.81.251 > 216.239.38.120: ICMP echo request, id 22984, seq 2, length 14
08:05:32.719773 IP 142.250.217.110 > 10.27.81.251: ICMP echo reply, id 22985, seq 2, length 14
08:05:32.719792 IP 216.239.38.120 > 10.27.81.251: ICMP echo reply, id 22984, seq 2, length 14
08:05:32.745302 IP 104.193.88.123 > 10.27.81.251: ICMP echo reply, id 22986, seq 2, length 14
08:05:32.872426 IP 10.27.81.201 > 1.1.1.1: ICMP echo request, id 41550, seq 0, length 64
08:05:32.922024 IP 1.1.1.1 > 10.27.81.201: ICMP echo reply, id 41550, seq 0, length 64
08:05:33.379910 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 6, length 64
08:05:33.380202 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 6, length 64
08:05:34.066848 IP 10.27.81.251 > 10.27.81.1: ICMP echo request, id 23587, seq 0, length 64
08:05:34.066873 IP 10.27.81.1 > 10.27.81.251: ICMP echo reply, id 23587, seq 0, length 64
08:05:34.384438 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 7, length 64
08:05:34.384748 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 7, length 64
08:05:35.387013 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 8, length 64
08:05:35.387175 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 8, length 64
08:05:35.610171 IP 10.27.81.250 > 216.239.38.120: ICMP echo request, id 18349, seq 0, length 14
08:05:35.614222 IP 10.27.81.250 > 142.251.211.238: ICMP echo request, id 18350, seq 0, length 14
08:05:35.619856 IP 10.27.81.250 > 104.193.88.123: ICMP echo request, id 18351, seq 0, length 14
08:05:35.651972 IP 216.239.38.120 > 10.27.81.250: ICMP echo reply, id 18349, seq 0, length 14
08:05:35.668621 IP 142.251.211.238 > 10.27.81.250: ICMP echo reply, id 18350, seq 0, length 14
08:05:35.692912 IP 104.193.88.123 > 10.27.81.250: ICMP echo reply, id 18351, seq 0, length 14
08:05:35.816110 IP 10.27.81.90 > 8.8.8.8: ICMP echo request, id 64088, seq 0, length 64
08:05:35.863191 IP 8.8.8.8 > 10.27.81.90: ICMP echo reply, id 64088, seq 0, length 64
08:05:35.884790 IP 10.27.81.251 > 216.239.38.120: ICMP echo request, id 23686, seq 0, length 14
08:05:35.894338 IP 10.27.81.251 > 142.251.215.238: ICMP echo request, id 23687, seq 0, length 14
08:05:35.894893 IP 10.27.81.251 > 104.193.88.77: ICMP echo request, id 23688, seq 0, length 14
08:05:35.926846 IP 216.239.38.120 > 10.27.81.251: ICMP echo reply, id 23686, seq 0, length 14
08:05:35.941411 IP 142.251.215.238 > 10.27.81.251: ICMP echo reply, id 23687, seq 0, length 14
08:05:35.971615 IP 104.193.88.77 > 10.27.81.251: ICMP echo reply, id 23688, seq 0, length 14
08:05:36.030861 IP 10.27.81.200 > 1.1.1.1: ICMP echo request, id 55886, seq 0, length 64
08:05:36.075680 IP 1.1.1.1 > 10.27.81.200: ICMP echo reply, id 55886, seq 0, length 64
08:05:36.391884 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 9, length 64
08:05:36.392131 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 9, length 64
08:05:36.610645 IP 10.27.81.250 > 216.239.38.120: ICMP echo request, id 18349, seq 1, length 14
08:05:36.614773 IP 10.27.81.250 > 142.251.211.238: ICMP echo request, id 18350, seq 1, length 14
08:05:36.620142 IP 10.27.81.250 > 104.193.88.123: ICMP echo request, id 18351, seq 1, length 14
08:05:36.653183 IP 216.239.38.120 > 10.27.81.250: ICMP echo reply, id 18349, seq 1, length 14
08:05:36.659589 IP 10.27.81.251 > 10.27.81.1: ICMP echo request, id 23792, seq 0, length 64
08:05:36.659607 IP 10.27.81.1 > 10.27.81.251: ICMP echo reply, id 23792, seq 0, length 64
08:05:36.666148 IP 142.251.211.238 > 10.27.81.250: ICMP echo reply, id 18350, seq 1, length 14
08:05:36.692978 IP 104.193.88.123 > 10.27.81.250: ICMP echo reply, id 18351, seq 1, length 14
08:05:36.820084 IP 10.27.81.90 > 8.8.8.8: ICMP echo request, id 64088, seq 1, length 64
08:05:36.866410 IP 8.8.8.8 > 10.27.81.90: ICMP echo reply, id 64088, seq 1, length 64
08:05:36.885163 IP 10.27.81.251 > 216.239.38.120: ICMP echo request, id 23686, seq 1, length 14
08:05:36.895265 IP 10.27.81.251 > 142.251.215.238: ICMP echo request, id 23687, seq 1, length 14
08:05:36.895753 IP 10.27.81.251 > 104.193.88.77: ICMP echo request, id 23688, seq 1, length 14
08:05:36.927345 IP 216.239.38.120 > 10.27.81.251: ICMP echo reply, id 23686, seq 1, length 14
08:05:36.942097 IP 142.251.215.238 > 10.27.81.251: ICMP echo reply, id 23687, seq 1, length 14
08:05:36.968220 IP 104.193.88.77 > 10.27.81.251: ICMP echo reply, id 23688, seq 1, length 14
08:05:37.392078 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 10, length 64
08:05:37.392249 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 10, length 64
08:05:37.611063 IP 10.27.81.250 > 216.239.38.120: ICMP echo request, id 18349, seq 2, length 14
08:05:37.616467 IP 10.27.81.250 > 142.251.211.238: ICMP echo request, id 18350, seq 2, length 14
08:05:37.620491 IP 10.27.81.250 > 104.193.88.123: ICMP echo request, id 18351, seq 2, length 14
08:05:37.655274 IP 216.239.38.120 > 10.27.81.250: ICMP echo reply, id 18349, seq 2, length 14
08:05:37.668079 IP 142.251.211.238 > 10.27.81.250: ICMP echo reply, id 18350, seq 2, length 14
08:05:37.694545 IP 104.193.88.123 > 10.27.81.250: ICMP echo reply, id 18351, seq 2, length 14
08:05:37.885657 IP 10.27.81.251 > 216.239.38.120: ICMP echo request, id 23686, seq 2, length 14
08:05:37.895698 IP 10.27.81.251 > 142.251.215.238: ICMP echo request, id 23687, seq 2, length 14
08:05:37.896072 IP 10.27.81.251 > 104.193.88.77: ICMP echo request, id 23688, seq 2, length 14
08:05:37.928228 IP 216.239.38.120 > 10.27.81.251: ICMP echo reply, id 23686, seq 2, length 14
08:05:37.942409 IP 142.251.215.238 > 10.27.81.251: ICMP echo reply, id 23687, seq 2, length 14
08:05:37.972267 IP 104.193.88.77 > 10.27.81.251: ICMP echo reply, id 23688, seq 2, length 14
08:05:38.055355 IP 10.27.81.201 > 1.1.1.1: ICMP echo request, id 63566, seq 0, length 64
08:05:38.098579 IP 1.1.1.1 > 10.27.81.201: ICMP echo reply, id 63566, seq 0, length 64
08:05:38.393834 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 11, length 64
08:05:38.394129 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 11, length 64
08:05:39.400829 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 12, length 64
08:05:39.401030 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 12, length 64
08:05:39.711356 IP 10.27.81.251 > 10.27.81.1: ICMP echo request, id 24534, seq 0, length 64
08:05:39.711375 IP 10.27.81.1 > 10.27.81.251: ICMP echo reply, id 24534, seq 0, length 64
08:05:40.403262 IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 13, length 64
08:05:40.403397 IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 13, length 64
08:05:40.799456 IP 10.27.81.250 > 216.239.38.120: ICMP echo request, id 18555, seq 0, length 14
08:05:40.805730 IP 10.27.81.250 > 142.251.33.110: ICMP echo request, id 18556, seq 0, length 14
08:05:40.812614 IP 10.27.81.250 > 104.193.88.77: ICMP echo request, id 18557, seq 0, length 14
08:05:40.841685 IP 216.239.38.120 > 10.27.81.250: ICMP echo reply, id 18555, seq 0, length 14
08:05:40.851763 IP 142.251.33.110 > 10.27.81.250: ICMP echo reply, id 18556, seq 0, length 14
^C
103 packets captured
6455 packets received by filter
0 packets dropped by kernel

Firewall enc0 interface:

root@gatekeeper:~ # tcpdump -i enc0 proto ICMP -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 262144 bytes
08:05:32.380179 (authentic,confidential): SPI 0xcff6d002: IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 5, length 64
08:05:32.380377 (authentic,confidential): SPI 0x0d12f320: IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 5, length 64
08:05:33.379898 (authentic,confidential): SPI 0xcff6d002: IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 6, length 64
08:05:33.380214 (authentic,confidential): SPI 0x0d12f320: IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 6, length 64
08:05:34.384425 (authentic,confidential): SPI 0xcff6d002: IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 7, length 64
08:05:34.384759 (authentic,confidential): SPI 0x0d12f320: IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 7, length 64
08:05:35.387000 (authentic,confidential): SPI 0xcff6d002: IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 8, length 64
08:05:35.387187 (authentic,confidential): SPI 0x0d12f320: IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 8, length 64
08:05:36.391873 (authentic,confidential): SPI 0xcff6d002: IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 9, length 64
08:05:36.392143 (authentic,confidential): SPI 0x0d12f320: IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 9, length 64
08:05:37.392064 (authentic,confidential): SPI 0xcff6d002: IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 10, length 64
08:05:37.392262 (authentic,confidential): SPI 0x0d12f320: IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 10, length 64
08:05:38.393821 (authentic,confidential): SPI 0xcff6d002: IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 11, length 64
08:05:38.394142 (authentic,confidential): SPI 0x0d12f320: IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 11, length 64
08:05:39.400815 (authentic,confidential): SPI 0xcff6d002: IP 10.27.84.1 > 10.27.81.60: ICMP echo request, id 26633, seq 12, length 64
08:05:39.401043 (authentic,confidential): SPI 0x0d12f320: IP 10.27.81.60 > 10.27.84.1: ICMP echo reply, id 26633, seq 12, length 64
^C
16 packets captured
16 packets received by filter
0 packets dropped by kernel


15

Virtual private networks / Re: IPSec VPN seems to work, but no communication?

« on: October 31, 2023, 10:21:54 pm »

Is there something that makes your setup more complicated than the norm, maybe a HA setup?

It is quite possible I caused the issue by turning on some feature I thought "sounded neat" or the like, not realizing the implications, however the overall setup is pretty basic: single router with two physical ports WAN and LAN, cable modem on the WAN, switch on the LAN. Nothing special or fancy there. I am using DNSBL on unbound, with a firewall rule set up to force all DNS queries through the local Unbound, but unless I *really* messed that up it should have no effect. The only plugins I am using are for LetsEncrypt and Dynamic DNS. System is fully updated (last checked this morning).

Is your outer tunnel address IPv4 or IPv6?

IPv4. Apparently my ISP doesn't offer IPv6 (at least, not to me), though I do have IPv6 support enabled with the idea that if/when it is offered I could use it. Could that be confusing things?

Do you SSH to an internal IP address or do you use a hostname that resolves to an external IP and expect NAT Reflection to happen?

Using IP addresses at the moment. My hope is that the VPN tunnel will push the local DNS server to the client, so internal addresses will resolve when connected to VPN, but since I can't get to even the LAN address of the router at the moment, that's obviously not working, so I'm just using IP addresses.