> I didn't have net.ipv4.ip_forward but I had > net.ipv4.conf.default.forwarding as proposed in /etc/sysctl.conf of > Debian: > # Uncomment the next line to enable packet forwarding for IPv4 > net.ipv4.conf.default.forwarding=1 > This worked well before with previous kernel with just that line. > > And here when it was broken, forward was still working in one > direction but not what came back. > That's why I blindly trusted ip_forward to be already =1 Hi all, Just for info I digged it a bit and now I came to more comprehensible conclusions that I wanted to share, who knows it could help some of you later... net.ipv4.conf.default.forwarding is =0 at boot time. When a new interface comes, it takes values from net.ipv4.conf.default branch At boot time, /etc/sysctl.conf is read and net.ipv4.conf.default.forwarding is set =1 So what happened is that eth0 came up before net.ipv4.conf.default.forwarding=1 (which didn't happen before) and so net.ipv4.conf.eth0.forwarding=0 But tap0 used by the vpn came later and got net.ipv4.conf.tap0.forwarding=1 So packets from tap0 were forwarded but not the replies coming from eth0. I could manually reproduce the problem with echo 0 > /proc/sys/net/ipv4/conf/eth0/forwarding echo 1 > /proc/sys/net/ipv4/conf/tap0/forwarding And to fix definitively the problem, I set in sysctl.conf: net.ipv4.conf.all.forwarding=1 which is apparently an alias to net.ipv4.ip_forward=1 Note that you could have forwarding activated with: net.ipv4.ip_forward=0 net.ipv4.conf.eth0.forwarding=1 net.ipv4.conf.tap0.forwarding=1 Which is more secure if you have more interfaces but don't want to activate forwarding on those other ones. Phil