can't establish pptp connection from windows client to freebsd mpd5/poptop when ipsec transport enabled. looks like some blocking of gre traffic occur. check same thing with windows 2003/linux (ipsec-tools/poptop) server - i can establish connection. on freebsd mpd get mesages from client but looks like client didn't get responses from server. mpd: [L-2] LCP: SendConfigReq #10 How-To-Repeat: spdflush; spdadd 192.168.250.0/24 192.168.250.0/24 any -P out ipsec esp/transport//require; spdadd 192.168.250.0/24 192.168.250.0/24 any -P in ipsec esp/transport//require; mpd51 default sample config with load pptp_server and corresponding changes in network address
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to networking team
Hi, the report is not too specific. Could you provide more details like - policies on Windows - confirm with tcpdump that no packets are going out on the real interface? - can you still see the packets on enc0? - any possible firewall setups? - ... In case you do not want to share all that in public you can mail me directly thought with "private IPs" this shouldn't be a problem. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time.
- policies on Windows the same to require ipsec on 192.168.250.0/24 both directions connection type: all network connectins with "accept usecured communication, but always respond using ipsec" turned off certificate type of authentication - confirm with tcpdump that no packets are going out on the real interface? I've got only esp packets, currently can't make tcpdump work with -E - can you still see the packets on enc0? not sure I understand what you mean. - any possible firewall setups? no server and host currently resides in same lan
State Changed From-To: open->feedback I am exchanging mails with the submitter to narrow down the problem.
Responsible Changed From-To: freebsd-net->bz I am exchanging mails with the submitter to narrow down the problem.
On Mon, 31 Mar 2008, Alexander Efimov wrote: Hi, > here goes mpd log, ... > > also I've prevoiously contacted with Alexander > Motin I Cc:ed him again as well as Gnats as from here on no more private data should be involved and we should document the findings. > his opinion was no packet came from client Well, yes, that is what your mpd log shows. Your tcpdump showed that you are receiving a Config-Reject from the Windows. As you can see it in enc(4) it should have passed IPsec already. So the question is "where is it lost"? Oh wait... hmmm. ng_pptpgre does not participate in the encap_attach dance - how would it? I wonder how the packets go into the ksocket and to ng_pptpgre and where they are going through ip_input or the like? I'll be away for two days but can check this (or review patches in case Mav comes up with something) once I am back. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time.
Could be a dup of kern/65616 ("IPSEC can't detunnel GRE packets after real ESP encryption".) -- Sergey Svishchev
Responsible Changed From-To: bz->gnn I shall not use bugzilla (at least until we will have a CLI).
There was a bug in old IPSEC implementation in FreeBSD kernel preventing correct delivery of incoming GRE packets after IPSEC decryption. One-line patch solved the problem: --- sys/netipsec/xform_ipip.c.orig 2015-11-07 10:41:56.000000000 +0100 +++ sys/netipsec/xform_ipip.c 2015-11-07 10:43:36.000000000 +0100 @@ -655,6 +655,7 @@ ipe4_encapcheck(const struct mbuf *m, in * also return a minimum priority when we want the packet * so any explicit gif tunnels take precedence. */ + if(mtod(m, struct ip *)->ip_p != IPPROTO_IPIP) return 0; return ((m->m_flags & M_IPSEC) != 0 ? 1 : 0); } #endif /* INET */ However, now we have new IPSEC implementation that has not this problem from the beginning.
*** Bug 65616 has been marked as a duplicate of this bug. ***