This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Up2date 4.011/4.012 broke DNAT after IPSEC tunnel?

It seems that after our upgrade to 4.011 and 4.012 which I applied Sept. 1, 2003, some of our DNAT rules which apply after an IPSEC tunnel no longer function correctly. 

Upon applying the update, I made only a few changes to the packet filter rules so that I could test out "LOG ACCEPT" - which logically shouldn't affect the NAT table. 

Scenerio:

We have two network to network VPN tunnels, both experiencing the same problem. Remote side is a /24 block, the local side terminates to a single host (/32). In order for the remote users to access an additional service (MSSQL) on a different machine, I had been DNATing that service from the single host IP to the SQL machine. Before the Up2date patch, this worked flawlessly. It seems after the up2dates, that we can no longer do this. 

I've tried widening the scope of the DNAT rule so that it doesn't look for the source IP, which still doesn't solve the problem. DNAT Rules which do not affect IP's that source from an IPSEC tunnel work just fine. 

I've set the packet filter to LOG ALLOW port 1433 for this service to see if I'm seeing any traffic, and thus far, I have not.

Remote site claims zero changes on their end.

Is this a regression, or do I need to change the nature of my rule as a result of the IPSEC routing adjustment made in 4.011? 


This thread was automatically locked due to age.