My configuration is pretty typical.

A Linux box acting as a firewall. ppp0 is my external interface (I use PPPoE).
eth0 is my internal interface (192.168.0.x).

My firewall is implemented using iptables. I use the iptables tutorial as a starting point. I use NAT to reach the other hosts on my internal network.

I have Skype installed on my primary host behind the firewall.

I have been searching the forums and trying various iptables changes. I have also been running ethereal while did my testing to try and get a clue about what I need to do.

So far, no luck.

Would someone please give me some clear instructions based on a working configuration?

TIA

After posting this. I tried a new set of iptables commands and tried calling another Skype member and had success!

Here are thos commands

IPTABLES="/sbin/iptables"
INET_IFACE="ppp0"

SkypePort=9158
SkypeHost=192.168.0.14

$IPTABLES -A INPUT -p tcp --dport $SkypePort -j ACCEPT
$IPTABLES -A INPUT -p udp --dport $SkypePort -j ACCEPT

$IPTABLES -A FORWARD -p tcp -d $SkypeHost --dport $SkypePort -j ACCEPT
$IPTABLES -A FORWARD -p udp -d $SkypeHost --dport $SkypePort -j ACCEPT

$IPTABLES -t nat -A PREROUTING -i $INET_IFACE -p tcp
--dport $SkypePort -j DNAT --to-destination $SkypeHost
$IPTABLES -t nat -A PREROUTING -i $INET_IFACE -p udp
--dport $SkypePort -j DNAT --to-destination $SkypeHost


After that success, I tried more closely following the format of dialing numbers with Skype out. I thought +12125551212 was equivalent to
+1 212 555 1212. I'm used to modems where the spaces in dialing strings are white space.

Anyway, I've had some succes.

Note all the chains are builtin. I placed my rules at the beginning of each chain just to make sure they were applied before anyone else got in.

Just the normal outgoing NAT rules are sufficient for Skype to work. Skype can figure out how to get through the firewall. I have everything closed off, but connecting out is allowed. This is the normal configuration for most people.

One disadvantage of this is that if both sides have such a firewall, the Skype protocol will then require bouncing the packets off some public server.

[quote="Ken Yap"]Just the normal outgoing NAT rules are sufficient for Skype to work. Skype can figure out how to get through the firewall. I have everything closed off, but connecting out is allowed. This is the normal configuration for most people.

One disadvantage of this is that if both sides have such a firewall, the Skype protocol will then require bouncing the packets off some public server.[/quote]



Ken,

Please post an example of the outgoing NAT rules to solve a non-Skype problem. I have used DNAT before and found I still needed a FORWARD chain rule to make it effective.

[quote]Ken,

Please post an example of the outgoing NAT rules to solve a non-Skype problem. I have used DNAT before and found I still needed a FORWARD chain rule to make it effective.
[/quote]

Just a MASQUERADING rule is sufficient:

# Masquerade outgoing connections over the External Interface
iptables -t nat -A POSTROUTING -o ${OUTSIDE_DEVICE} -j MASQUERADE

If you can surf, you can skype.

And that's not much of a disadvantage at all.

But I agree, jwramseyjr is trying too hard. There is no special firewall rules need for Skype, unless you block all outgoing traffic, in which case even surfing would not work.

OK! I removed all of my changes to my IPTABLES firewal. Obviously, I can surf the web just fine.

And it appears to work!

I still worry a bit about Skype. It has this tendency to just go boom.

I run FC3 (with almost all the updates -- I build a kernel from source for Win4Lin, so I don't do that unless necessary.

I also have to do -- artsdsp -m skype because I use KDE.

Hopefully, things will get more stable over time.

I restrict the TCP ports I allow in, so I get messages like this. Port 9158 is may magic Skype port. Oddly, Skype OUT still works as do member to member calls.

Apr 3 16:29:46 igor kernel: IPT INPUT packet died: IN=ppp0 OUT= MAC= SRC=85.206.87.45 DST=66.219.135.59 LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=4714 DF PROTO=TCP SPT=1682 DPT=9158 WINDOW=65535 RES=0x00 SYN URGP=0


I take it, that this fails and then Skype works out another way to solve the problem.

Lots of information in the FAQ about this. There is also
another somewhat dated but still interesting paper on this here:
http://arxiv.org/pdf/cs.NI/0412017

If you really want to, you can open a port on your firewall for incoming packets on the port skype uses
(see the settings) and route it to your machine. This is seldom necessary, but it does not hurt anything.

You simply route that like any other inbound connection you might have.

Buy the way, you will find Shorewall a LOT easier to manage IPTables with, rather than writing all the rules
yourself. http://www.shorewall.net

Note that port-forwarding to the Linux version of Skype currently does not help very much as recent versions do not detect this correctly and still relay traffic even though it's not needed.
Older versions in the 0.9x were working fine, but at some point a regression appeared (don't know from which version on...)

[quote=bonbons]Note that port-forwarding to the Linux version of Skype currently does not help very much as recent versions do not detect this correctly and still relay traffic even though it's not needed.
Older versions in the 0.9x were working fine, but at some point a regression appeared (don't know from which version on...)[/quote]

Actually, I confirmed this morning that 1.0.0.20 does work OK for direct packet exchange. I was the callee, using Linux 1.0.0.20. The caller was running Skype on Windows (unknown version). Seemed to work OK when I was doing the calling too.

I verified with tcpdump that the UDP packets were flowing directly between the two systems.

Maybe there is some problem when both parties are using Linux. I haven't tried that yet.

[quote=sihde][quote=bonbons]Note that port-forwarding to the Linux version of Skype currently does not help very much as recent versions do not detect this correctly and still relay traffic even though it's not needed.
Older versions in the 0.9x were working fine, but at some point a regression appeared (don't know from which version on...)[/quote]

Actually, I confirmed this morning that 1.0.0.20 does work OK for direct packet exchange. I was the callee, using Linux 1.0.0.20. The caller was running Skype on Windows (unknown version). Seemed to work OK when I was doing the calling too.

I verified with tcpdump that the UDP packets were flowing directly between the two systems.

Maybe there is some problem when both parties are using Linux. I haven't tried that yet.[/quote]Are you shure the other side is also behind a NAT router? For me it has been relaying the calls, even when Windows versions were in same LAN as myself!