Hi all,
I have a rather unusual problem. I'm using the ethertap device to do some
experimentation with demand-dialing. The idea is to hold outgoing packets
in "limbo" until the PPP connection is up, then re-inject them into the
kernel networking layer at the right time. This isn't just for use with
PPP, but also for my Tunnel Vision VPN software
(http://www.worldvisions.ca/tunnelv/) and any other dynamically-created
network connections I need to put together in the near future.
Anyway, it looks something like this:
Packet to internet --> ethertap --> [User App] --> ethertap --> PPP
The [User App] is responsible for connecting to the Internet, and it stores
up some packets until the PPP connection is established. At that time, the
default route is set through the PPP interface instead of the ethertap, and
bouncing the packet back out the ethertap should result in it getting routed
to the PPP interface.
This mostly works. However, although I have no configured firewall rules,
the kernel is terribly paranoid about what it is willing to route from the
ethertap to the PPP link.
There appear to be two separate problems.
1) The kernel refuses to route packets with a source address on an
interface where the kernel does not have a route. That is, if eth0 is
the network 192.168.1.0/24, the kernel won't accept packets from
192.168.1.0/24 on any other interface, including the ethertap.
This is obviously for protection from IP spoofing, and it makes sense.
Plus, I finally figured out that you can disable it with the
/proc/sys/net/ipv4/conf/tap0/rp_filter sysctl.
But I'm stumped with the second problem:
2) The kernel refuses to route packets with a source IP address owned by
this system. That is, if dummy0 has IP address 192.168.1.1, then the
kernel drops all packets I inject through the ethertap from that
address. This is frustrating, because it prevents me from doing
exactly what I want, which is to re-transmit packets originally sent
from the local host.
I've played with various sysctls to no avail. Can anyone help me here?
Unsolicited opinion: the kernel seems to be taking network policy into its
own hands here. Such restrictions can be handled by the IP firewall -- why
do we have to have them in the main routing code as well?
Thanks,
Avery
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
