I havent done any research on the net2phone protocol, but like ftp and
irc(dcc) and real audio, ipmasq probably needs a protocol handler to work
correctly with net2phone, so any attempts to masquerade a net2phone
connection will probably fail. There is a generic handler with the 2.2.x
kernels ipchains (and maybe the 2.0.x kernels) for unsupported protocols,
you can give that a try.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Boris
> Sent: Wednesday, July 21, 1999 12:45 PM
> To: [EMAIL PROTECTED]
> Subject: tcpdump shows packet loss by ipportfw ...
>
>
> Dear firewall gurus,
>
> I am sending my question to this list as I hope it's "on topic here",
> and there are people who can easily figure the answer out. If not -
> I apologize and please let me know what's a better place to ask...
>
> Here is a pretty weard problem that drives me crazy. All I wanted
> was to make net2phone work with my linux firewall. (I am using
> a linux box (2.0.36 kernel) with ipfwadm (IP masquerade)
> and ipportfw (port re-direct) installed. To do what I wanted,
> in addition to allowing tcp/udp traffic from the LAN with
>
> ipfwadm -F -a accept -m -P tcp -S 192.168.0.0/24
> ipfwadm -F -a accept -m -P udp -S 192.168.0.0/24
>
> I had to forward one TCP port (6613) and one UDP port (6615) to
> the local machine with:
>
> /sbin/ipportfw -A -t$Firewall_IP/6613 -R 192.168.0.1/6613
> /sbin/ipportfw -A -u$Firewall_IP/6615 -R 192.168.0.1/6615
>
> But net2phone still didn't work.
>
> Then I run tcpdump on these ports on both LAN and WAN interfaces.
> What I saw was udp traffic to/from port 6615 going back and forth
> just fine, while tcp traffic from the WAN to the port 6613 stopped dead
> when arriving to the WAN interface (it never showed up to LAN
> interface...)
>
> The destination address on those packages was shown to be 0.0.0.0
> (why or why?) by tcpdump, so I am wondering how I can forward
> these packets to my client machine. (Oh yeah, and how can I find more
> about the content of raw packets in the dump files, obtained using -w
> option of tcpdump - attached d6615.0, d6615.1, d6613.0, d6613.1 ?).
>
> Any help/hints would be greatly appreciated...
>
> Thanks,
>
> Boris.
>
> P.S. The tcpdump results for TCP port 6613 on both eth0 and
> eth1(LAN) are as follows:
>
> === TCP port 6613 on the WAN (tcpdump -n -i eth0 -vv port 6613):
> 14:08:39.656009 169.132.65.5.36902 > 0.0.0.0.6613: S
> 1929898218:1929898218(0) win 8760 <mss 1460> (DF) (ttl 239, id 52506)
> 14:08:39.656009 169.132.65.5.36902 > 0.0.0.0.6613: S
> 1929898218:1929898218(0) win 8760 <mss 1460> (DF) (ttl 239, id 52506)
> 14:08:43.156009 169.132.65.5.36902 > 0.0.0.0.6613: S
> 1929898218:1929898218(0) win 8760 <mss 1460> (DF) (ttl 239, id 52507)
> 14:08:43.156009 169.132.65.5.36902 > 0.0.0.0.6613: S
> 1929898218:1929898218(0) win 8760 <mss 1460> (DF) (ttl 239, id 52507)
> 14:08:49.566009 169.132.65.5.36902 > 0.0.0.0.6613: S
> 1929898218:1929898218(0) win 8760 <mss 1460> (DF) (ttl 239, id 52508)
> 14:08:49.566009 169.132.65.5.36902 > 0.0.0.0.6613: S
> 1929898218:1929898218(0) win 8760 <mss 1460> (DF) (ttl 239, id 52508)
> 14:08:58.976009 169.132.65.5.36902 > 0.0.0.0.6613: R
> 1929898219:1929898219(0) win 8760 (DF) (ttl 239, id 52509)
> 14:08:58.976009 169.132.65.5.36902 > 0.0.0.0.6613: R
> 1929898219:1929898219(0) win 8760 (DF) (ttl 239, id 52509)
>
> 8 packets received by filter
> 0 packets dropped by kernel
>
>
> === TCP port 6613 on the LAN (tcpdump -n -i eth1 -vv port 6613):
>
> 0 packets received by filter
> 0 packets dropped by kernel
>
>
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
