thanks for helping with this.
James Cameron wrote:
> If the new evidence shows the ICMP packet is from a router, then I
> think it is the router at fault, or not being able to interoperate with
> Linux PPTP. Your home LAN firewall is also a router.
Yes. I should have earlier, but I will describe the config in more detail.
the system at ool is at home. it's running fedora core 3 and the
firestarter firewall package. It's a router, dns, NAT box for the
clients on the home LAN. the ISP is optimum online.
the other box, at the xo address, is the firewall box at the office.
it's fedora core 3, running firestarter and poptop software.
> Good. Yes, same thing. The big question then is which interface of
> which host has the address ool-44c56f30.dyn.optonline.net?
That's on the client side of the picture
> If this is a router, then the router (which may be your home firewall)
> has lost the association for the connection and is responding to the
> server's GRE packets with the ICMP protocol unreachable message, causing
> the server to cancel the connection.
> In your initial message in the thread on 25th June, the server side log
> showed read from GRE socket failed with EIO, but in a subsequent message
> later that day and on 30th June when the problem returned, it showed
> EPROTO "Protocol not available". This EPROTO is consistent with receipt
> of the ICMP protocol unreachable message above. So the tcpdump evidence
> has determined the cause of the connection failure, as logged by the
> The question becomes; why did ool-44c56f30.dyn.optonline.net send this
> ICMP response? Some common answers are;
> (a) it has no rule to forward GRE packets inside, because it hasn't been
> configured with one, (unlikely since you say it works sometimes),
It has rules built in that function with microsoft VPN's, which, as you
pointed out later, aren't precisely the same as poptop.
> (b) it has no rule to forward GRE packets inside, because it hasn't
> detected the outgoing tunnel attempt, e.g. because it is programmed only
> to expect a Microsoft VPN data stream which is slightly different to the
> Linux PPTP data stream,
This is likely.
> (c) it already has a session to this server from another client behind
> it, is operating in NAT (network address translation) mode, and is
> unable to use connection numbering to identify the different session,
> (multiple tunnels to the same server are not supported by pptpd on Linux
> if they all originate from the same IP address as perceived by the
Don't think that's the case, it's just me playing with this for now on
> (d) it recently restarted and lost knowledge of the connection that was
> (e) software defect in the handling of the port 1723 stateful inspection
> and protocol 47 forwarding.
> Presumably the client connects fine if it is placed on the outside
> interface of the firewall host? That would exclude the firewall as
I haven't tried that since doing that would be extremely difficult.
However I am toying with the idea of doing the connection between the
two linux machines on a permanent always-on basis between the lans as a
test. that would eliminate the windows host as the cause.
The thing I don't understand is why rebooting the poptop server allows
the client to connect if the problem seems to be originating from the
originating firewall side. Why it works for a while and then doesn't is
>>I rebooted the server that's running poptop, and was able to connect.
>>No icmp messages on either system.
> Now that's interesting. Could it be that there is an old session still
> present as far as ool-44c56f30.dyn.optonline.net is concerned? (see (c)
>>I wait about half an hour...
> What happens in this half an hour, as far as
> ool-44c56f30.dyn.optonline.net is concerned? (I'm focusing on this host
> because it's the source of the ICMP protocol unreachable response).
>>I don't think this is a client-firewall-side issue, as we can connect
>>to other microsoft VPNs from the local lan here just fine.
> That's no proof, sorry. If you could connect to other Linux VPNs from
> the local LAN, then I would accept your proposition. Linux VPN is not
> Microsoft VPN. While we intend that it interoperate, there are
>>On the machine that's running poptop server I've added these rules to
> Why did you do that? These rules should have no effect, unless you were
> blocking packets already.
>># allow vpn connections
>>$IPT -A INPUT -i $IF -p tcp --dport 1723 \
>> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
> If you didn't have TCP port 1723 packets accepted already, you wouldn't
> be getting anywhere near the EPROTO response. Without these packets
> accepted, pptpd would never generate any GRE responses.
>>Adding those rules and restarting the firewall has no effect, and
>>stopping and restarting the poptop service has no effect.
> That's interesting too. But can you verify that stopping the service
> causes all the pppd processes to disappear? I didn't think it did. And
> if a pppd process still exists from a previous connection, the firewall
> may have been confused.