-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a situation where some Poptop/PPTP sessions (only with FC5/Shorewall to FC5/Shorewall firewall in between) cause the following to appear in the state table (shorewall show connections). unknown 47 420 src=XX.234.79.183 dst=XX.234.137.226 packets=2 bytes=130 [UNREPLIED] src=XX.234.137.226 dst=XX.234.79.183 packets=0 bytes=0 mark=0 use=1 This prevents another connection attempt succeeding from that firewalls IP address until that entry ages out of the table. My question. Would I use the "Action" section of Shorewall to tell the firewall to either accept all IP 47 (GRE) packets, even if it thinks it''s unsolicited, or to accept them even if there is such an entry in the state table? If so, just point me in that direction. Thanks, Joe -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.6 (Build 6060) iQA/AwUBRMDl/AVMDrRdN8NGEQJZaACeK6rYBQwgV/BYigbkHQ92s/59GFUAn0Zj rsutegUfyZi1/bXl+IHdUdzV =j+tf -----END PGP SIGNATURE----- ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a situation where some Poptop/PPTP sessions (only with FC5/Shorewall to FC5/Shorewall firewall in between) cause the following to appear in the state table (shorewall show connections). unknown 47 420 src=XX.234.79.183 dst=XX.234.137.226 packets=2 bytes=130 [UNREPLIED] src=XX.234.137.226 dst=XX.234.79.183 packets=0 bytes=0 mark=0 use=1 This prevents another connection attempt succeeding from that firewalls IP address until that entry ages out of the table. My question. Would I use the "Action" section of Shorewall to tell the firewall to either accept all IP 47 (GRE) packets, even if it thinks it''s unsolicited, or to accept them even if there is such an entry in the state table? If so, just point me in that direction. Thanks, Joe -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.6 (Build 6060) iQA/AwUBRMDl/AVMDrRdN8NGEQJZaACeK6rYBQwgV/BYigbkHQ92s/59GFUAn0Zj rsutegUfyZi1/bXl+IHdUdzV =j+tf -----END PGP SIGNATURE----- ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
HK4ME wrote:> > > I have a situation where some Poptop/PPTP sessions (only with FC5/Shorewall > to FC5/Shorewall firewall in between) cause the following to appear in the > state table (shorewall show connections). > > > unknown 47 420 src=XX.234.79.183 dst=XX.234.137.226 packets=2 bytes=130 [UNREPLIED] src=XX.234.137.226 dst=XX.234.79.183 packets=0 bytes=0 mark=0 use=1 > > > This prevents another connection attempt succeeding from that firewalls > IP address until that entry ages out of the table. > > My question. Would I use the "Action" section of ShorewallWhat do you mean by ''the "Action" section of Shorewall''?> to tell the firewall to either accept all IP 47 (GRE) packets, > even if it thinks it''s unsolicited, or to accept them even if > there is such an entry in the state table? > > If so, just point me in that direction. >I think you are mis-diagnosing the problem. Entries in the conntrack table like you see above should not prevent connections. They merely indicate that XX.2234.137.183 has sent a GRE packet to XX.234.137.226 and the latter has not replied. Is XX.234.79.183 configured as a PPTP client and is XX.234.79.226 configured as a PPTP server as described in http://www.shorewall.net/PPTP.htm? Are you loading the PPTP connection tracking module? -Tom PS -- we all know what the value of XX is from looking at your SMTP headers so I don''t know why you think you need to hide it. -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I meant this section, "http://shorewall.net/Actions.html". Never used
it, but it sounded like it might fit the bill.
As for the "XX", I try to be a "little" bit discreet in a
public forum :-)
Ok, the map is like this ...
(A) (B) (C) (D)
WinXP/PPTPClient ---FC5-Firewall------FC5-Firewall/PPTPServer-----RemoteLAN
(24.234.222.114) (24.234.79.183)
Point (A) - Interior LAN with XP Pro client trying to initiate a PPTP session
with the remote firewall.
Point (B) - eth0/Internet interface of a FC1/Shorewall V3 firewall which is
NAPT''ing the PPTP request from the inside.
Point (C) - eth0/Internet interface of the remote FC5/Shorewall V3 which is
running PopTop''s pptpd services.
Again, the scenario, with a bit more detail than the last post.
If there are no ppp sessions established on the "24.234.79.183"
firewall, a connection will be established every time. If a ppp session IS
established on the "79.183" firewall, and another pptp connection is
tried from a client that is behind another FC5/Shorewall firewall, the
connection fails. The following appears in the contrack tables on each firewall
(Shorewall show connections) ...
(On the 24.234.222.114 firewall)
unknown 47 492 src=24.234.79.183 dst=24.234.222.114 [UNREPLIED]
src=24.234.222.114 dst=24.234.79.183 use=1
(On the 24.234.79.183 firewall)
unknown 47 536 src=24.234.115.163 dst=24.234.79.183 packets=61 bytes=7423
src=24.234.79.183 dst=24.234.115.163 packets=56 bytes=5089 mark=0 use=1
(this is the already established ppp session)
- ---------------------------------------------------------------------
unknown 47 569 src=24.234.79.183 dst=24.234.222.114 packets=1 bytes=65
[UNREPLIED] src=24.234.222.114 dst=24.234.79.183 packets=0 bytes=0 mark=0 use=1
I ran 3 simultaneous Ethereal captures at points A, B, & C and show a
stripped down version of the packet summary lines
The capture on the firewall on the client side (Point A)looks like this ...
Source Destination Protocol Info
10.89.100.201 24.234.79.183 TCP 50555 > 1723 [SYN] Seq=0 Ack=0
Win=65535 Len=0 MSS=1460
24.234.79.183 10.89.100.201 TCP 1723 > 50555 [SYN, ACK] Seq=0 Ack=1
Win=5840 Len=0 MSS=1460
10.89.100.201 24.234.79.183 PPTP Start-Control-Connection-Request
24.234.79.183 10.89.100.201 TCP 1723 > 50555 [ACK] Seq=1 Ack=157
Win=6432 Len=0
24.234.79.183 10.89.100.201 PPTP Start-Control-Connection-Reply
10.89.100.201 24.234.79.183 PPTP Outgoing-Call-Request
24.234.79.183 10.89.100.201 PPTP Outgoing-Call-Reply
10.89.100.201 24.234.79.183 PPTP Set-Link-Info
10.89.100.201 24.234.79.183 PPP LCP Configuration Request
24.234.79.183 10.89.100.201 TCP 1723 > 50555 [FIN, ACK] Seq=189
Ack=349 Win=7504 Len=0
10.89.100.201 24.234.79.183 TCP 50555 > 1723 [FIN, ACK] Seq=349
Ack=190 Win=65347 Len=0
24.234.79.183 10.89.100.201 TCP 1723 > 50555 [ACK] Seq=190 Ack=350
Win=7504 Len=0
The capture at Point B looks like this ...
Source Destination Protocol Info
24.234.222.114 24.234.79.183 TCP 50555 > pptp [SYN] Seq=0 Ack=0
Win=65535 Len=0 MSS=1460
24.234.79.183 24.234.222.114 TCP pptp > 50555 [SYN, ACK] Seq=0
Ack=1 Win=5840 Len=0 MSS=1460
24.234.222.114 24.234.79.183 PPTP Start-Control-Connection-Request
24.234.79.183 24.234.222.114 TCP pptp > 50555 [ACK] Seq=1
Ack=157 Win=6432 Len=0
24.234.79.183 24.234.222.114 PPTP Start-Control-Connection-Reply
24.234.222.114 24.234.79.183 PPTP Outgoing-Call-Request
24.234.79.183 24.234.222.114 PPTP Outgoing-Call-Reply
24.234.222.114 24.234.79.183 PPTP Set-Link-Info
24.234.79.183 24.234.222.114 PPP LCP Configuration Request
24.234.222.114 24.234.79.183 ICMP Destination unreachable (Protocol
unreachable)
24.234.79.183 24.234.222.114 TCP pptp > 50555 [FIN, ACK]
Seq=189 Ack=349 Win=7504 Len=0
24.234.222.114 24.234.79.183 TCP 50555 > pptp [FIN, ACK]
Seq=349 Ack=190 Win=65347 Len=0
24.234.79.183 24.234.222.114 TCP pptp > 50555 [ACK] Seq=190
Ack=350 Win=7504 Len=0
The capture at Point C looks like this ...
Source Destination Protocol Info
24.234.222.114 24.234.79.183 TCP 50555 > 1723 [SYN] Seq=0 Len=0
MSS=1460
24.234.79.183 24.234.222.114 TCP 1723 > 50555 [SYN, ACK] Seq=0
Ack=1 Win=5840 Len=0 MSS=1460
24.234.222.114 24.234.79.183 PPTP Start-Control-Connection-Request
24.234.79.183 24.234.222.114 TCP 1723 > 50555 [ACK] Seq=1 Ack=157
Win=6432 Len=0
24.234.79.183 24.234.222.114 PPTP Start-Control-Connection-Reply
24.234.222.114 24.234.79.183 PPTP Outgoing-Call-Request
24.234.79.183 24.234.222.114 PPTP Outgoing-Call-Reply
24.234.79.183 24.234.222.114 PPP LCP Configuration Request
24.234.222.114 24.234.79.183 PPTP Set-Link-Info
24.234.222.114 24.234.79.183 ICMP Destination unreachable (Protocol
unreachable)
24.234.79.183 24.234.222.114 TCP 1723 > 50555 [FIN, ACK] Seq=189
Ack=349 Win=7504 Len=0
24.234.222.114 24.234.79.183 TCP 50555 > 1723 [FIN, ACK] Seq=349
Ack=190 Win=65347 Len=0
24.234.79.183 24.234.222.114 TCP 1723 > 50555 [ACK] Seq=190
Ack=350 Win=7504 Len=0
As long as the [UNREPLED] entry is in the contrack tables, the ICMP Destination
Unreachable packet keeps being sent, and any attempts at initiating a session
fails. If you wait for it to age out of the table, the connection will now
succeed. You can then drop it, and reestablish it as many times as you want.
Having a long period of ppp inactivity will usually cause the situation again.
What I was originally looking for was a way to have Shorewall tell the firewall
to always accept IP 47 so this situation would not develop.
I have the raw Ethereal capture files available if needed.
Joe
***********************************************************************
> -----Original Message-----
> From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-
> users-bounces@lists.sourceforge.net] On Behalf Of Tom Eastep
> Sent: Friday, July 21, 2006 8:29 AM
> To: Shorewall Users
> Subject: Re: [Shorewall-users] Quick Question on [UNREPLIED] in the state
> tables
>
> * PGP Signed by an unknown key: 07/21/06 at 08:28:52
> HK4ME wrote:
> >
> >
> > I have a situation where some Poptop/PPTP sessions (only with
> FC5/Shorewall
> > to FC5/Shorewall firewall in between) cause the following to appear in
> the
> > state table (shorewall show connections).
> >
> >
> > unknown 47 420 src=XX.234.79.183 dst=XX.234.137.226 packets=2
bytes=130
> [UNREPLIED] src=XX.234.137.226 dst=XX.234.79.183 packets=0 bytes=0 mark=0
> use=1
> >
> >
> > This prevents another connection attempt succeeding from that
firewalls
> > IP address until that entry ages out of the table.
> >
> > My question. Would I use the "Action" section of Shorewall
>
> What do you mean by ''the "Action" section of
Shorewall''?
>
> > to tell the firewall to either accept all IP 47 (GRE) packets,
> > even if it thinks it''s unsolicited, or to accept them even if
> > there is such an entry in the state table?
> >
> > If so, just point me in that direction.
> >
>
> I think you are mis-diagnosing the problem. Entries in the conntrack table
> like
> you see above should not prevent connections. They merely indicate that
> XX.2234.137.183 has sent a GRE packet to XX.234.137.226 and the latter has
> not
> replied.
>
> Is XX.234.79.183 configured as a PPTP client and is XX.234.79.226
> configured as
> a PPTP server as described in http://www.shorewall.net/PPTP.htm?
>
> Are you loading the PPTP connection tracking module?
>
> -Tom
> PS -- we all know what the value of XX is from looking at your SMTP
> headers so I
> don''t know why you think you need to hide it.
> --
> Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
> Shoreline, \ http://shorewall.net
> Washington USA \ teastep@shorewall.net
> PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
>
> * Unknown Key
> * 0x97E30CB2 (L)
-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.6 (Build 6060)
iQA/AwUBRMKhsQVMDrRdN8NGEQLxcwCggw8OtImHUmhKMWRwXQ12YVziPAwAn0B8
5ic2LivOYWAToyEcd3ntEmbX
=5wak
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net''s Techsay panel and you''ll get the chance
to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
HK4ME wrote:> > If there are no ppp sessions established on the "24.234.79.183" firewall, a connection will be established every time. If a ppp session IS established on the "79.183" firewall, and another pptp connection is tried from a client that is behind another FC5/Shorewall firewall, the connection fails. The following appears in the contrack tables on each firewall (Shorewall show connections) ... > > (On the 24.234.222.114 firewall) > unknown 47 492 src=24.234.79.183 dst=24.234.222.114 [UNREPLIED] src=24.234.222.114 dst=24.234.79.183 use=1 > > (On the 24.234.79.183 firewall) > unknown 47 536 src=24.234.115.163 dst=24.234.79.183 packets=61 bytes=7423 src=24.234.79.183 dst=24.234.115.163 packets=56 bytes=5089 mark=0 use=1 > (this is the already established ppp session) > --------------------------------------------------------------------- > unknown 47 569 src=24.234.79.183 dst=24.234.222.114 packets=1 bytes=65 [UNREPLIED] src=24.234.222.114 dst=24.234.79.183 packets=0 bytes=0 mark=0 use=1 >It looks to me like the problem is on the FC1 boxes and not on the FC5 box. Do you see GRE packets being rejected on the FC1 boxes when this happens? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> HK4ME wrote: >> If there are no ppp sessions established on the "24.234.79.183" firewall, a connection will be established every time. If a ppp session IS established on the "79.183" firewall, and another pptp connection is tried from a client that is behind another FC5/Shorewall firewall, the connection fails. The following appears in the contrack tables on each firewall (Shorewall show connections) ... >> >> (On the 24.234.222.114 firewall) >> unknown 47 492 src=24.234.79.183 dst=24.234.222.114 [UNREPLIED] src=24.234.222.114 dst=24.234.79.183 use=1 >> >> (On the 24.234.79.183 firewall) >> unknown 47 536 src=24.234.115.163 dst=24.234.79.183 packets=61 bytes=7423 src=24.234.79.183 dst=24.234.115.163 packets=56 bytes=5089 mark=0 use=1 >> (this is the already established ppp session) >> --------------------------------------------------------------------- >> unknown 47 569 src=24.234.79.183 dst=24.234.222.114 packets=1 bytes=65 [UNREPLIED] src=24.234.222.114 dst=24.234.79.183 packets=0 bytes=0 mark=0 use=1 >> > > > It looks to me like the problem is on the FC1 boxes and not on the FC5 box. Do > you see GRE packets being rejected on the FC1 boxes when this happens? > > -TomJoe: Just to see if I have this right, the box at 24.234.222.114 has many pptp clients trying to connect to the same poptop server at 24.234.79.183, and your complaint is that only one client at a time can connect to the server. Any new connections that are attempted from behind the box at .114 will fail (unless it is the same client trying), until the conntrack entries expire? You were asked earlier if the pptp modules were loaded, but we have not had an answer to that question. It''s been awhile for me and pptp, but on .114 if you do a lsmod, are the ip_nat_pptp and ip_conntrack_pptp modules loaded? If not you might want to try loading them. The lsmod info is captured with a "shorewall dump", that is why a dump is requested with requests for support. I''m unsure if the poptop server would need the ip_conntrack_pptp module loaded, but a masq box, like .114, would require both modules to be loaded to have multi-client support. Like I said its, been awhile.... Just my 2 cents worth, good luck, Jerry ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I''ve run into this problem for years using FC1 boxes (don''t know if it''s tied to Fedora or not), but it''s been very intermittent. However, now that I have converted a few to FC5, it seems to show up rather consistently. The strange thing is though, once the [UNREPLIED] ages out, the problem goes away for awhile, at least for those same firewall pairs. On FC1, it takes a heck of a long time to age out, on the FC5 boxes it seems they changes the age out time to be something a bit shorter. In answer to you question Tom, FC1 and FC5 boxes, which the client is behind, both exhibit the same symptoms. IOW, I''ve tried it FC1 to FC5, and FC5 to FC5, and it happens both ways. However, I have noticed that having the PPTP endpoint be a FC5 box makes it a lot worse. Joe> -----Original Message----- > From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall- > users-bounces@lists.sourceforge.net] On Behalf Of Tom Eastep > Sent: Sunday, July 23, 2006 8:36 AM > To: Shorewall Users > Subject: Re: [Shorewall-users] Quick Question on [UNREPLIED] in the state > tables > > * PGP Signed by an unknown key: 07/23/06 at 08:35:41 > HK4ME wrote: > > > > If there are no ppp sessions established on the "24.234.79.183" > firewall, a connection will be established every time. If a ppp session IS > established on the "79.183" firewall, and another pptp connection is tried > from a client that is behind another FC5/Shorewall firewall, the > connection fails. The following appears in the contrack tables on each > firewall (Shorewall show connections) ... > > > > (On the 24.234.222.114 firewall) > > unknown 47 492 src=24.234.79.183 dst=24.234.222.114 [UNREPLIED] > src=24.234.222.114 dst=24.234.79.183 use=1 > > > > (On the 24.234.79.183 firewall) > > unknown 47 536 src=24.234.115.163 dst=24.234.79.183 packets=61 > bytes=7423 src=24.234.79.183 dst=24.234.115.163 packets=56 bytes=5089 > mark=0 use=1 > > (this is the already established ppp session) > > --------------------------------------------------------------------- > > unknown 47 569 src=24.234.79.183 dst=24.234.222.114 packets=1 bytes=65 > [UNREPLIED] src=24.234.222.114 dst=24.234.79.183 packets=0 bytes=0 mark=0 > use=1 > > > > > It looks to me like the problem is on the FC1 boxes and not on the FC5 > box. Do > you see GRE packets being rejected on the FC1 boxes when this happens? > > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > > * Unknown Key > * 0x97E30CB2 (L)-----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.6 (Build 6060) iQA+AwUBRMPvPwVMDrRdN8NGEQJAtQCgkonv3zEHDiwZrxx5XLJ6MSD2bh0AkQF4 Ato9YEJpfPwzYbsMaR3dSR8=TbS9 -----END PGP SIGNATURE----- ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV