# [SOLVED] iptables emerge --sync

## thesheff17

I'm trying to get emerge --sync working with iptables.  I have a local emerge sync server running on ip 10.1.10.37.  Everything works fine when the firewall is disabled on the client.  This is my iptables to accept port 873.  emerge --sync hangs when it is trying to find the timestamp on the server.  Is there another port that I need open in order for this to work.  

My iptables entry

iptables -A INPUT -i eth0 -p tcp -s 10.1.10.37 -d $publicIP --dport 873 -j ACCEPTLast edited by thesheff17 on Thu Apr 06, 2006 4:42 am; edited 2 times in total

----------

## SinoTech

Since it works when the clients firewall is disabled, the problem is not the servers firewall. So please post the relevant lines of the client configuration.

Regards,

Sino

----------

## thesheff17

The client config is:

iptables -A INPUT -i eth0 -p tcp -s 10.1.10.37 -d $publicIP --dport 873 -j ACCEPT

This may be wrong all together.  Please let me know.

----------

## SinoTech

 *thesheff17 wrote:*   

> The client config is:
> 
> iptables -A INPUT -i eth0 -p tcp -s 10.1.10.37 -d $publicIP --dport 873 -j ACCEPT
> 
> This may be wrong all together.  Please let me know.

 

You've to define a output rule as well, that's since the client has to establish a connection first, and therefore has to send an outgoing packet before.

The rule for incoming packages can be omited if you accept all packages from already establish connections.

That's how it looks for me

```

INTIF1='eth0'

...

# Allow outgoing traffic for rsync

$IPTABLES -A OUTPUT -o $INTIF1 -p tcp --dport 873 -j ACCEPT 

...

# Accept all packets from already established connections

$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 

...

```

Regards,

Sino

----------

## thesheff17

At this time I have no rules for OUTPUT rules.  I have only created INPUT rules.

----------

## SinoTech

 *thesheff17 wrote:*   

> At this time I have no rules for OUTPUT rules.  I have only created INPUT rules.

 

Then non of your applications could connect to outside. I recommend to read a tutorial about iptables before continue your work. Nobody is able to help you if you not even know the basics of that stuff.

See http://www.netfilter.org/documentation/ for the basics.

Regards,

Sino

----------

## thesheff17

I know what I am doing.  There are more rules and I have no problem connecting in. Like my 443 port as well as ssh.

Below is my entire firewall settings:

publicIP=<publicIP>

iptables -P INPUT DROP

iptables -F

iptables -A INPUT -i eth0 -p tcp -d $publicIP --dport 443 -j ACCEPT 

iptables -A INPUT -i eth0 -p tcp -s 10.1.10.0/24 -d $publicIP --dport 22 -j ACCEPT 

iptables -A INPUT -i eth0 -p tcp -s 10.1.10.37 -d $publicIP --dport 873 -j ACCEPT

----------

## SinoTech

 *thesheff17 wrote:*   

> 
> 
> I know what I am doing.  There are more rules and I have no problem connecting in. Like my 443 port as well as ssh.
> 
> [...]
> ...

 

But for "emerge --sync" you've to connect out and not in  :Wink: .

 *thesheff17 wrote:*   

> 
> 
> [...]
> 
> Below is my entire firewall settings:
> ...

 

So that's the whole firewall setting on your client? I told you to create rules for outgoging packages, but as it seems you haven't create them, right? So  ... 

- If you want to get help, then please try the suggestions and post the result

- If you really know what you're doing, as stated before, and you don't want to give the suggestion a try, please don't ask why it doesn't work  :Wink: 

Regards,

Sino

----------

## thesheff17

my default setting for ALL OUTPUT is ACCEPT.  I do not define any rules for OUTPUT.  So there must be something trying to come in that isn't setup correctly.

----------

## SinoTech

 *thesheff17 wrote:*   

> my default setting for ALL OUTPUT is ACCEPT.  I do not define any rules for OUTPUT.  So there must be something trying to come in that isn't setup correctly.

 

OK, I've overseen the default policy for OUTPUT. Anyway, I am sure the only port you need for rsync is 873. BTW did you remember that you allow incoming traffic for a sole IP only? Is that IP adress the one of your rsync server?

Regards,

Sino

EDIT:

Even if there's a additional port you've to open, you could easily tell iptables to accept packates of related connections:

```

# Accept all packets from related and already established connections

$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

```

Using this command, you don't have to care about any additional ports.

----------

## thesheff17

thanks for the help, but still no luck.  Yes my server has a static ip of 10.1.10.37.  I'm thinking it has to do with some kind of port that transfers the timestamp.  any ideas? you know of a program that will monitor exactly what the pc is doing for all ports and packets?  If so I can disable the firewall and run that program while it syncs and see what it is really doing.

----------

## SinoTech

You could use ethereal to log the network traffic.

Regards,

Sino

----------

## thesheff17

my network activity.  I see port 873 coming in, but what is this...

  2.738316 00:13:21:f9:c3:6f -> ff:ff:ff:ff:ff:ff ARP Who has 10.1.10.1?  Tell 10.1.10.37

Do I have to add something for this to be accepted into my firewall?

BELOW IS THE OUTPUT

grep "10.1.10.37" ./networkOutput.txt | more

  2.727086 $publicIP -> 10.1.10.37   TCP 37953 > 873 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=176643504 TSER=0 WS=2

  2.738316 00:13:21:f9:c3:6f -> ff:ff:ff:ff:ff:ff ARP Who has 10.1.10.1?  Tell 10.1.10.37

  2.754753   10.1.10.37 -> $publicIP TCP 873 > 37953 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=100223972 TSER=176 643504 WS=2

  2.754830 $publicIP -> 10.1.10.37   TCP 37953 > 873 [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=176643511 TSER=100223972

  2.755273 $publicIP -> 10.1.10.37   RSYNC Client Initialisation (Version  27\n)

  2.768550   10.1.10.37 -> $publicIP RSYNC Server Initialisation (Version  27\n)

  2.768596 $publicIP -> 10.1.10.37   TCP 37953 > 873 [ACK] Seq=13 Ack=13 Win=5840 Len=0 TSV=176643515 TSER=100223979

  2.768614   10.1.10.37 -> $publicIP TCP 873 > 37953 [ACK] Seq=13 Ack=13 Win=5792 Len=0 TSV=100223979 TSER=176643511

  2.768764 $publicIP -> 10.1.10.37   RSYNC Client Query

  2.779193   10.1.10.37 -> $publicIP TCP 873 > 37953 [ACK] Seq=13 Ack=28 Win=5792 Len=0 TSV=100223982 TSER=176643515

  2.983892   10.1.10.37 -> $publicIP RSYNC Server MOTD

  2.984059 $publicIP -> 10.1.10.37   RSYNC Module list

  2.998654   10.1.10.37 -> $publicIP TCP 873 > 37953 [ACK] Seq=25 Ack=37 Win=5792 Len=0 TSV=100224036 TSER=176643568

  2.998681 $publicIP -> 10.1.10.37   RSYNC Module list

  3.011688   10.1.10.37 -> $publicIP TCP 873 > 37953 [ACK] Seq=25 Ack=155 Win=5792 Len=0 TSV=100224040 TSER=176643572

  3.011727   10.1.10.37 -> $publicIP RSYNC Module list[Malformed Packet]

  3.011823 $publicIP -> 10.1.10.37   RSYNC Module list[Malformed Packet]

  3.068056   10.1.10.37 -> $publicIP TCP 873 > 37953 [ACK] Seq=29 Ack=159 Win=5792 Len=0 TSV=100224054 TSER=176643575

  3.068099 $publicIP -> 10.1.10.37   RSYNC Module list

  3.081611   10.1.10.37 -> $publicIP TCP 873 > 37953 [ACK] Seq=29 Ack=196 Win=5792 Len=0 TSV=100224057 TSER=176643589

  3.081638   10.1.10.37 -> $publicIP RSYNC Module list

  3.082506 $publicIP -> 10.1.10.37   RSYNC Module list[Malformed Packet]

  3.093839   10.1.10.37 -> $publicIP RSYNC Module list

  3.094056 $publicIP -> 10.1.10.37   RSYNC Module list[Malformed Packet]

  3.101149   10.1.10.37 -> $publicIP RSYNC Module list

  3.143746 $publicIP -> 10.1.10.37   TCP 37953 > 873 [ACK] Seq=204 Ack=81 Win=5840 Len=0 TSV=176643608 TSER=100224063

  3.148597   10.1.10.37 -> $publicIP RSYNC Module list

  3.148715 $publicIP -> 10.1.10.37   TCP 37953 > 873 [ACK] Seq=204 Ack=97 Win=5840 Len=0 TSV=176643610 TSER=100224075

  3.149607 $publicIP -> 10.1.10.37   RSYNC Module list[Malformed Packet]

  3.158148   10.1.10.37 -> $publicIP TCP 873 > 37953 [FIN, ACK] Seq=97 Ack=208 Win=5792 Len=0 TSV=100224077 TSER=176643610

  3.172000 $publicIP -> 10.1.10.37   TCP 37953 > 873 [FIN, ACK] Seq=208 Ack=98 Win=5840 Len=0 TSV=176643615 TSER=100224077

  3.180748   10.1.10.37 -> $publicIP TCP 873 > 37953 [ACK] Seq=98 Ack=209 Win=5792 Len=0 TSV=100224083 TSER=176643615

----------

## SinoTech

 *thesheff17 wrote:*   

> my network activity.  I see port 873 coming in, but what is this...
> 
>   2.738316 00:13:21:f9:c3:6f -> ff:ff:ff:ff:ff:ff ARP Who has 10.1.10.1?  Tell 10.1.10.37
> 
> [...]
> ...

 

Here 10.1.10.37 asks for the MAC adress of 10.1.10.1. I wonder since I didn't see a response back to the requestor ... anyway, I didn't have a rule for that too, so I wonder if the packet is getting blocked or not. BTW since your computers can talk to each other, it shouldn't be a problem.

And unfortunatelly I haven't seen any statement in log, that there's a additional port is needed. Sry, but I've got currently no clue on what's going wrong  :Sad: .

Regards,

Sino

----------

## thesheff17

The solution. sinoTech you were right! Here is the entry that fixed everything. Thank you very much sinoTech for all your help.

iptables -A INPUT -i eth0 -p tcp -s 10.1.10.37 -d $publicIP -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

The reason for this because: rync send the first packet out on some random port. and the server accepts it on 873. Then the server sends the packet back out on 873 and the client expects the packet to come back on that random port.  Below is a log that proves this issue.  Can anyone confirm this about rync? Below it shows already two different ports coming back twards the publicIp 34445 and 34446.

0.000000 $publicIP -> 10.1.10.37   TCP 34445 > 873 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=194679631 TSER=0 WS=2

  0.002017   10.1.10.37 -> $publicIP TCP 873 > 34445 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=118259887 TSER=19

  1.404544   10.1.10.37 -> $publicIP TCP 873 > 34445 [SYN, ACK] Seq=0 Ack=1 Win=23168 Len=0 MSS=1460 TSV=118260237 TSER=1

 12.988514 $publicIP  -> 10.1.10.37   TCP 34446 > 873 [SYN] Seq=0 Ack=0 Win=23360 Len=0 MSS=1460 TSV=194682878 TSER=0 WS=2

 12.989367   10.1.10.37 -> $publicIP  TCP 873 > 34446 [SYN, ACK] Seq=0 Ack=1 Win=23168 Len=0 MSS=1460 TSV=118263133 TSER=1

 13.406546   10.1.10.37 -> $publicIP  TCP 873 > 34446 [SYN, ACK] Seq=0 Ack=1 Win=23168 Len=0 MSS=1460 TSV=118263237 TSER=1

----------

## SinoTech

Oh yes, shame on me. I've totally forgotten that client uses a non-public port (>1024) when opening a connection  :Sad: . BTW I can't tell you why rsync uses two ports nor if it is the normal behaviour (I'll check that if coming back home).

Regards,

Sino

----------

## DaveArb

 *thesheff17 wrote:*   

> The reason for this because: rync send the first packet out on some random port. and the server accepts it on 873. Then the server sends the packet back out on 873 and the client expects the packet to come back on that random port.  Below is a log that proves this issue.  Can anyone confirm this about rync? Below it shows already two different ports coming back twards the publicIp 34445 and 34446.

 

That is normal behavior not only for rsync, but for pretty much everything. Clients allocate a (pseudo-)random high port to connect to a commonly known port on a server.

Dave

----------

