On 22 Jun 99, at 18:45, Rod Moffitt wrote about
"[Masq] Re: Masq&Diald: When 'initi":
| Thanks for your reply Fred.
No problem, sorry it wasn't helpfull. This one probably won't be
either...
| On Mon, 21 Jun 1999, Fred Viles wrote:
|
| > On 21 Jun 99, at 12:23, Rod Moffitt wrote about
| > "[Masq] Masq&Diald: When 'initial' ":
| >
| > | Masq&Diald: When 'initial' traffic that brings up link is UDP kernel DOES
| > | not masq - it merely forwards...
| >
| > I don't see any evidence of that.
|
| I am getting packets being denied on the OUT path of my ppp0 interface,
| ie 'fw-out deny ppp0'.
Exactly.
| If they were being masquerading or interface to
| interface forwarded then 'fw-out' would be changed to 'fw-fwd'.
No, that would be true only if the forward was being *denied*, since
you are only logging denys. The fact that there are ne fw-fwd denies
logged points to the forwarding/masquerading being done. Also, if
the packet was denied by the forward rule, it would not make it to
the output rule.
| Therefore
| the kernel is not observing my request to have masquerading on all packets
| from the 'private' machine.
Nope. My point was that the denies are occuring and being logged at
the *output* phase does not in any way show that
masquerading/forwarding is not occuring.
| > |...
| > | Now Masquerading did work for all packet types from the firewall machine.
| >
| > When you run from the firewall machine, you are not using masquerade
| > at all.
|
| All the firewall machine knows is 'what are the source addresses' to
| masquerade from and 'what interface' to masquerade over. Therefore as long
| as the firewall machine lies within 'what are the source addresses' the
| kernel will masquerade them to.
No, I think you misunderstand how masquerading works. Masquerading
is triggered by packet forwarding. If the packet is not forwarded
from one interface to another, it can not be masqueraded for the
simple reason that it is not tested against the forwarding rules.
Packets originated on the firewall host are not being *forwarded*.
Also, when a packet is originated on the firewall machine, its source
address is the IP address associated with the interface the packet is
being sent on. So when the FW machine sends packets to external
hosts, the source address will *not* be within your private net.
| I am able to use lynx or ftp to internet
| sites no problem from any firewall with masquerading.
With no problem, but without masquerading.
| > |...
| > | Anyone have an idea?
| > |
| > | Jun 19 20:12:32 router kernel: IP fw-out deny ppp0 UDP W.X.Y.Z:61232 A.B.C.D:53
|L=65 S=0x00 I=4096 F=0x0000 T=31
| > | Jun 19 20:12:47 router kernel: IP fw-out deny ppp0 UDP W.X.Y.Z:61233 E.F.G.H:53
|L=65 S=0x00 I=4352 F=0x0000 T=31
| > | Jun 19 20:13:02 router kernel: IP fw-out deny ppp0 UDP W.X.Y.Z:61232 A.B.C.D:53
|L=65 S=0x00 I=4608 F=0x0000 T=31
| > | Jun 19 20:13:22 router kernel: IP fw-out deny ppp0 UDP W.X.Y.Z:61233 E.F.G.H:53
|L=65 S=0x00 I=4864 F=0x0000 T=31
| >
| > W.X.Y.Z is your public IP, right? So the packets are being properly
| > masqueraded, but they are then rejected by your *output* filter.
|
| No - W.X.Y.Z is the Win95 host (behind the firewall with
| masquerading) trying to do a DNS lookup on some internet
| DNS server at A.B.C.D and E.F.G.H.
So W.X.Y.Z is a private address? Now *that* is evidence that
masquerading is not occuring. OTOH, the source port number is in the
range used by masquerading, showing that it *is* occuring. That's
why I guessed W.X.Y.Z was your public IP.
I'm not sure what could cause this to occur. Perhaps something about
the timing of when the interface is brought up? At masquerade time
your external IP isn't known yet?
|...
| > What is $PUBLIC_INT -vs- $DIALD_INT? More important, what are your
| > output rules?
|
| When using diald you have a 'virtual' interface called 'sl0' (ie slip)
| that is used to 'detect' traffic - upon which it will bring up the 'real'
| link, this case 'ppp0'. I have to masquerade across both since diald
| switches over traffic to the ppp0 from it's sl0.
OK. You still didn't say what your output rules look like, but it
probably doesn't matter. Since the source IP wasn't changed from the
internal address, it is expected that your ouptut rules deny those
packets (stuffed masquerade).
- Fred Viles <mailto:[EMAIL PROTECTED]>
_______________________________________________
Masq maillist - [EMAIL PROTECTED]
http://tiffany.indyramp.com/mailman/listinfo/masq
Admin requests can be handled by web (above) or [EMAIL PROTECTED]
