Skip to contentSkip to conversation

tap0 or ppp0?

DISCUSSION Owain McGuire 3 participants 3 messages Mar 21, 2003 – Mar 30, 2003

lore
Share & tools
lore
#0 lore raw

Simple question really??

I have upgraded from diald 0.9 to 1.0 and sorted out all of the ethertap stuff. The only thing is that the masqueraded machines don't seem to be able to bring up the ppp connections themselves. The "server" machine can though. I have followed the IP_Masq_Howto for 2.4 kernels but I have a question for the rc.firewall-2.4 script. Should the external interface be tap0 or ppp0? I am confused as to how the flow or handoever of traffic from tap0 to ppp0 works.

I currently have it set to ppp0 which seems fine when the link is up since ifconfig gives me:

ppp0 Link encap:Point-to-Point Protocol

          inet addr:158.152.189.169  P-t-P:158.152.1.222

Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:3520 errors:0 dropped:0 overruns:0 frame:0 TX packets:3294 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3
RX bytes:1531219 (1.4 Mb) TX bytes:250596 (244.7 Kb)

tap0 Link encap:Ethernet HWaddr FE:FD:00:00:00:00
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:142 (142.0 b) TX bytes:142 (142.0 b) Interrupt:5

But when the link is down it is:

tap0 Link encap:Ethernet HWaddr FE:FD:00:00:00:00

          inet addr:158.152.189.169  Bcast:0.0.0.0

Mask:255.255.255.255
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:142 (142.0 b) TX bytes:142 (142.0 b) Interrupt:5

which suggests that ppp0 as an external interface is wrong.

Or is it that my default route isn't set up correctly? Should it not point to tap0?

Destination Gateway Genmask Flags Metric Ref
Use Iface
demon-du.demon. * 255.255.255.255 UH 0 0
0 ppp0
10.0.0.0 * 255.255.255.0 U 0 0
0 eth0
loopnet * 255.0.0.0 U 0 0
0 lo
default * 0.0.0.0 U 0 0
0 ppp0

Thanks in advance.

O.

#1 lore raw

Hi Owain,

I'm not sure what your firewall script looks like, but I think it will have to have masquerade rules for both the ppp0 and tap0 interfaces.

It sounds like there are no forward/masq rules for tap0, so diald doesn't get any packets from the masqueraded machines if the link is down.

You might try to edit the script and duplicate the masq rules substituting tap0 for ppp0.

Hope that helps!

Mark.

Quoted 70 lines · Owain McGuire

Simple question really??

I have upgraded from diald 0.9 to 1.0 and sorted out all of the ethertap stuff. The only thing is that the masqueraded machines don't seem to be able to bring up the ppp connections themselves. The "server" machine can though. I have followed the IP_Masq_Howto for 2.4 kernels but I have a question for the rc.firewall-2.4 script. Should the external interface be tap0 or ppp0? I am confused as to how the flow or handoever of traffic from tap0 to ppp0 works.

I currently have it set to ppp0 which seems fine when the link is up since ifconfig gives me:

ppp0 Link encap:Point-to-Point Protocol

          inet addr:158.152.189.169  P-t-P:158.152.1.222

Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:3520 errors:0 dropped:0 overruns:0 frame:0 TX packets:3294 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3
RX bytes:1531219 (1.4 Mb) TX bytes:250596 (244.7 Kb)

tap0 Link encap:Ethernet HWaddr FE:FD:00:00:00:00
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:142 (142.0 b) TX bytes:142 (142.0 b) Interrupt:5

But when the link is down it is:

tap0 Link encap:Ethernet HWaddr FE:FD:00:00:00:00

          inet addr:158.152.189.169  Bcast:0.0.0.0

Mask:255.255.255.255
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:142 (142.0 b) TX bytes:142 (142.0 b) Interrupt:5

which suggests that ppp0 as an external interface is wrong.

Or is it that my default route isn't set up correctly? Should it not point to tap0?

Destination Gateway Genmask Flags Metric Ref
Use Iface
demon-du.demon. * 255.255.255.255 UH 0 0
0 ppp0
10.0.0.0 * 255.255.255.0 U 0 0
0 eth0
loopnet * 255.0.0.0 U 0 0
0 lo
default * 0.0.0.0 U 0 0
0 ppp0

Thanks in advance.

O.

-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
In reply to Owain McGuire
Quoted 9 lines · Owain McGuire

Simple question really??

I have upgraded from diald 0.9 to 1.0 and sorted out all of the ethertap stuff. The only thing is that the masqueraded machines don't seem to be able to bring up the ppp connections themselves. The "server" machine can though. I have followed the IP_Masq_Howto for 2.4 kernels but I have a question for the rc.firewall-2.4 script. Should the external interface be tap0 or ppp0? I am confused as to how the flow or handoever of traffic from tap0 to ppp0 works.

Without knowing what rc.firewall-2.4 does exactly it's difficult to be sure. However you generally want the proxy interface to either allow any packet out or to have exactly the same fiewalling of outgoing packets that the real link would (which may reduce some false triggers depending how you have diald itself configured).

You do _not_ want masquerading active on the proxy interface. It gets sort of complicated to follow, but on a machine doing forwarding with dynamic addresses on the diald link diald will send proxy packets back to the kernel via the proxy interface and the kernel will then route them out the real interface, masquerading if necessary. If you masquerade on the proxy interface as well you pick up a likely bogus source address which prevents the connection from working until the client times out and tries again - if that's after the link has timed out the retry won't work either.

The best answer is probably to make the ppp interface an external, the proxy a wide open internal (remember the real link has all the firewalling you need anyway), and configure diald carefully to only bring the link up for the traffic you want.

Mike