Bug #15998
closed
IPSec bypass rules cause interface failure
0%
Description
When we had version 2.6.3, we migrated an IPSec to a dataline. The only way we found to force IPSec to let go of the traffic to permit it to be sent on the dataline, was the IPSec bypass rules.
After upgrading to 2.7.0, we started having interface failures. Even after upgrading to 2.7.2, these failures persisted. When we tried to investigate the nature of the failure, we found that packets on the failed interfaces were being sent with a MAC address in the ethernet header that did not match the MAC address of the interface. When the failure occured, a reboot was required to resume proper operation.
This phenomenon occured on 3 separate pfSense installations, all of them on virtual machines. 2 in house, and 1 hosted by Y-Tech.
Eventually, we were able to conclude that the failure was related to the IPSec bypass rules. However, even when these rules were removed, the failures persisted. Only when the configuration, without the IPSec bypass rules, was imported into a new installation, did the failures stop.
We're assuming that the low usage rate of the IPSec bypass rules prevented this issue from coming up sooner. Of course, this low usage rate also reduces the urgency of a resolution
Thank you for your time.
Updated by Jim Pingle 8 months ago
- Status changed from New to Rejected
There isn't nearly enough information here to make any conclusions or identify anything specific. It sounds like an issue in the configuration or the environment, not the OS, but there isn't enough information to say one way or the other. For example, it sounds sort of like what would happen if your rules matched and forwarded broadcast traffic for one subnet out another unrelated interface with a route-to rule.
This site is not for support or diagnostic discussion to gather more information, however.
For assistance in solving problems, please post on the Netgate Forum .
See Reporting Issues with pfSense Software for more information.