Topics

Hi,

I recently switched from a SonicWall router to an OPNsense appliance. Behind this appliance I have a multi-tenant Exchange server and a VM running Proxmox Mail Gateway spam filter. When someone in the multi-tenant Exchange server emails anyone else that the spam filter is filtering email for, obviously reflection comes into play and it works. However, the sender IP address detected by the spam filter is the OPNsense appliance's LAN IP instead of the WAN IP:

Mar 27 15:05:22 mx01 postfix/smtpd[12870]: D43C632D238: client=localhost.localdomain[127.0.0.1], orig_client=unknown[192.168.7.1]

With the SonicWall, the orig_client was correctly detected as the WAN IP. This is causing problems with some domains with enforced SPF.

I have OPNsense 19.1.4 set up with multi-wan on a small appliance. It has been in place and functioning great for quite a while, but last night it went offline and I wasn't on-site this morning so I walked users through power cycling the router and everything came back up.

I'm looking through the logs and the gateway log is the only one with relevant information:

Aug 2 08:15:54 dpinger: GATEWAY ALARM: WANGW (Addr: 8.8.8.8 Alarm: 0 RTT: 11001ms RTTd: 101ms Loss: 15%)
Aug 2 08:15:54 dpinger: WANGW 8.8.8.8: Clear latency 11001us stddev 101us loss 15%
Aug 2 08:15:45 dpinger: GATEWAY ALARM: WAN2_GWv4 (Addr: 8.8.4.4 Alarm: 0 RTT: 20396ms RTTd: 2472ms Loss: 13%)
Aug 2 08:15:45 dpinger: WAN2_GWv4 8.8.4.4: Clear latency 20396us stddev 2472us loss 13%
Aug 2 08:15:21 dpinger: WANGW 8.8.8.8: sendto error: 64
Aug 2 08:15:20 dpinger: WANGW 8.8.8.8: sendto error: 64
Aug 2 08:15:18 dpinger: GATEWAY ALARM: WAN2_GWv4 (Addr: 8.8.4.4 Alarm: 1 RTT: 0ms RTTd: 0ms Loss: 100%)
Aug 2 08:15:18 dpinger: WAN2_GWv4 8.8.4.4: Alarm latency 0us stddev 0us loss 100%
Aug 2 08:15:18 dpinger: GATEWAY ALARM: WANGW (Addr: 8.8.8.8 Alarm: 1 RTT: 0ms RTTd: 0ms Loss: 100%)
Aug 2 08:15:18 dpinger: WANGW 8.8.8.8: Alarm latency 0us stddev 0us loss 100%
Aug 2 08:15:16 dpinger: send_interval 1000ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 8.8.4.4 bind_addr 98.191.85.167 identifier "WAN2_GWv4 "
Aug 2 08:15:16 dpinger: send_interval 1000ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 8.8.8.8 bind_addr 216.255.247.46 identifier "WANGW "

All of these entries are from right after the router booted back up though. I've looked through:
https://docs.opnsense.org/manual/logging.html

There aren't any relevant entries anywhere from before it went down that I could find. Any idea where I should look to see what happened?

Thanks!

I have a very basic LAN/WAN configuration with static WAN address and a few ipsec vpn connections. I started investigating this one location because of poor VPN performance.

I did the "old ping MTU test" and found some interesting results that I'm not able to replicate anywhere else.

If I run this command while behind my opnsense: ping 8.8.8.8 -f -l 1473
I get the following: "Packet needs to be fragmented but DF set."

If I run this command while behind my opnsense: ping 8.8.8.8 -f -l 1472
I get the following: "Request timed out."

I don't begin to get replies until I get to: ping 8.8.8.8 -f -l 512
512 bytes and below reply.

I've put a laptop in place of my opnsense appliance with the static IP and it works as expected. Packets under 1473 bytes all reply. Can anyone shed some light on this? I'm running version 19.1.4.

Thanks!

I have a customer with 3 locations. Everything was initially setup with OPNsense 17 with IPSec VPN setup between all three locations. Everything worked perfectly. A second WAN was added to one location. Since then I can only communicate with devices one way - devices in the other two offices can ping everything in every location. If I am in the office with 2 WAN connections, traffic will not route through the VPN. I can only communicate with devices on that local network.

I read in release notes that there were some routing fixes, so i've performed all updates to 18.7.10 and still am having the same problem. Anyone have any ideas?