FreeBSD 10.0 RELEASE and problems with ip forwarding
Many changes have been made to the mechanisms for working with the IP stack v4 in the new release of FreeBSD 10.0.
Including the ip fordwarding mechanism was changed. In particular, the kernel options IPFIREWALL_FORWARD option was removed as described in the updates for the release. Now this functionality is always on and the need for such an option simply disappears. But there is a small nuance.
Its essence lies in the following - if ipfw rules are used, then everything works except for one but often used case.
ipfw fwd XXXX all from AAAA to BBBB Error condition - the source packet according to the rules of routing must go to the interface int_1 and the address XXXX is located behind another interface int_2.
The ipfw fwd XXXX rule sends packets to / dev / null in a situation where H.H.X.X is on a different interface than the original package
Such rules are often used for organizing parallel physical channels for duplication or for organizing different routes based on the source address of packets.
The packet enters the log but it does not exist on the output interface.
As it turned out, this problem manifested itself in other people. Here is the way to solve the problem. Adding one missing line resolves the issue in the current release. After rebuilding the kernel, the rules behave predictably and work, although in the industrial version it is too early to start it - I have not yet completed the check for correctness in other places.
Interestingly enough, there is very little material about this problem and when I came across this behavior, ipfw didn’t even immediately understand what was happening.
')
Ps. In some cases, I see a duplication of outgoing packets that have passed through the ipfw fwd rule, which in general does not do any harm - but the behavior is still strange. Especially because zadvoenie sometimes. Not yet found the logic.
Pps. I also met the recommendation to upgrade to 10.0.Stable where this IP stack error was fixed. But release is still release. And the dynamic version “in development” is obviously not that suitable for work. Well, the conclusion - unfortunately 10-ka is not yet recommended for industrial use ... Which is a great pity.
Including the ip fordwarding mechanism was changed. In particular, the kernel options IPFIREWALL_FORWARD option was removed as described in the updates for the release. Now this functionality is always on and the need for such an option simply disappears. But there is a small nuance.
Its essence lies in the following - if ipfw rules are used, then everything works except for one but often used case.
ipfw fwd XXXX all from AAAA to BBBB Error condition - the source packet according to the rules of routing must go to the interface int_1 and the address XXXX is located behind another interface int_2.
The ipfw fwd XXXX rule sends packets to / dev / null in a situation where H.H.X.X is on a different interface than the original package
Such rules are often used for organizing parallel physical channels for duplication or for organizing different routes based on the source address of packets.
The packet enters the log but it does not exist on the output interface.
As it turned out, this problem manifested itself in other people. Here is the way to solve the problem. Adding one missing line resolves the issue in the current release. After rebuilding the kernel, the rules behave predictably and work, although in the industrial version it is too early to start it - I have not yet completed the check for correctness in other places.
Interestingly enough, there is very little material about this problem and when I came across this behavior, ipfw didn’t even immediately understand what was happening.
')
Ps. In some cases, I see a duplication of outgoing packets that have passed through the ipfw fwd rule, which in general does not do any harm - but the behavior is still strange. Especially because zadvoenie sometimes. Not yet found the logic.
Pps. I also met the recommendation to upgrade to 10.0.Stable where this IP stack error was fixed. But release is still release. And the dynamic version “in development” is obviously not that suitable for work. Well, the conclusion - unfortunately 10-ka is not yet recommended for industrial use ... Which is a great pity.
Source: https://habr.com/ru/post/212813/
All Articles