https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227086
--- Comment #3 from Eugene Grosbein <eu...@freebsd.org> --- (In reply to Marek from comment #2) The problem is the address 10.20.20.1 that is bounded first to "local system" by means of assigning it to local side of tun0. Then, an attempt is made to assign it to "remote" part of tun1 that is accomplished with creation of another route to 10.20.20.1/32 overriding existing one. Such configuration worked in older versions of FreeBSD breaking traffic flow to such an address via loopback interface but recent versions does not allow overrides to loopback routes anymore. However, your task can be solved with much simplier configuration. In fact, you need not local "client" OpenVPN/tun1 at all. Just assign 10.20.20.10/32 to loopback interface as alias in /etc/rc.conf: ifconfig_lo0_alias0="inet 10.20.20.10/32" And your services like mail, www, etc. will work as usual. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
