Development May 2015

development@lists.ipfire.org

12 participants
25 discussions

[GIT]: Pull request - pango: Generate modules cache on install and update
by Stefan Schantl 28 May '15

28 May '15

Please pull from git://git.ipfire.org/people/stevee/ipfire-3.x.git tags/pango-module-cache to get these changes: pango: Generate modules cache on install and update if not present. (2015-05-28 20:39:16 +0200) ---------------------------------------------------------------- Stefan Schantl (1): pango: Generate modules cache on install and update if not present. pango/pango.nm | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)

1 0

Pull request - pending updates
by Matthias Fischer 27 May '15

27 May '15

2 1

Re: static via dhcp/pppoe + additonal static IPs (UK BT infinity, AT/CH UPC Business, CH Init7)
by Alexander Weber 27 May '15

27 May '15

Hi, Haette auch vermutet einfach den GW von der DHCP Adresse herzunehmen tut, aber wohl nein. Ich glaube das grosse Problem liegt daran, dass eine IP aus einem Subnet fix per DHCP kommt und die weiteren IPs aus einem Anderen. Vielleicht bin ich auch zu ungeduldig, siehe http://shorewall.net/shorewall_setup_guide.htm#ProxyARP kommender Absatz CAUTION und der Provider hats nicht geaendert - dagegen spricht aber ein traceroute (siehe Attachments). Pfsense hat es geloest, da heist es VIP, ich lad mir mal die Distro und schaue mir an wie es dort geloest ist, vielleicht bringt das ja noch eine Idee. Cheers, Alex ________________________________ Sent: Tue May 05, 2015 12:51 pm From: MichaelTremer<http://forum.ipfire.org/memberlist.php?mode=viewprofile&u=3&sid=6a529573201…> Recipient: NODeeJay<http://forum.ipfire.org/memberlist.php?mode=viewprofile&u=3059&sid=6a529573…> Hi, das sind jetzt nicht gerade all zu viele Informationen... Grundsätzlich ist das egal welche Subnetzmaske du benutzt. Das Gateway ist doch sowieso klar oder? Oder ist wirklich eine Adresse aus dem Netz das Gateway für das Netz? Können wir die ganze Diskussion auch auf der Devel Mailing Liste führen? Dann sind mehr Leute dabei... NODeeJay wrote:Hey Michael, ich hab jetzt alles was mir einfiel versucht, mit SNAT/DNAT, ohne, mit dem Gateway vom der DHCP Adresse, mit einer Route zum gerouteten Netz etc. In allen Faellen gehen lt. tcpdump auch ACKs raus, kommen aber nie an. Arping liefert uebrigens auch immer 100% Verlust. Vielleicht bin ich mittelerweile auch Konsolenblind geworden. Config statische via DHCP IP: 212.51.153.253 SN: 255.255.255.0 GW: 212.51.153.1 BC: 212.51.153.255 fixe: 85.195.224.64/29 was m.E. funktionierte sollte nicht gerouted: Code: Select all<http://forum.ipfire.org/ucp.php?i=pm&mode=view&f=0&p=4822> $ ifconfig red0:0 85.195.224.64 netmask 255.255.255.255 up $ /usr/sbin/arping -c 1 -w 1 -i red0 -S 85.195.224.64 212.51.153.1 gerouted: Code: Select all<http://forum.ipfire.org/ucp.php?i=pm&mode=view&f=0&p=4822> $ ifconfig red0:0 85.195.224.65 netmask 255.255.255.248 up $ /usr/sbin/arping -c 1 -w 1 -i red0 -S 85.195.224.65 85.195.224.64 und die Route unter den statischen mit 85.195.224.64/29 gw: 85.195.224.65 eingetragen. beim Provider ist lt Provider alles i.O. Vielleicht siehst Du noch wo das Problem sein koennte, im Prinzip ist es ja nichts anderes als auf DD-WRT http://www.dd-wrt.com/phpBB2/viewtopic. ... 639#211639<http://www.dd-wrt.com/phpBB2/viewtopic.php?p=211639#211639>. Cheers, Alex

2 4

Pull request - pending updates
by Matthias Fischer 25 May '15

25 May '15

Hi all, Some minor updates again. Version-Numbers in round brackets show actual version in 'next', handle as you like: ;-) urlgrabber: Update to 3.10 (3.9.1) http://git.ipfire.org/?p=people/mfischer/ipfire-2.x.git;a=commit;h=a935c14a… unzip: Update to 6.0 (5.52) http://git.ipfire.org/?p=people/mfischer/ipfire-2.x.git;a=commit;h=4c54faff… krb5: Update to 1.13.2 (1.12.1) http://git.ipfire.org/?p=people/mfischer/ipfire-2.x.git;a=commit;h=70304c10… snort 2.9.7.3 with QuantumInsert-Patch (2.9.7.0) http://git.ipfire.org/?p=people/mfischer/ipfire-2.x.git;a=commit;h=01ec1ee4… If there are problems, please let me know! Regards Matthias -- tails, linux, USB, CD, secure desktop, IRC, truecrypt, tor, onion

1 0

Re: AW: IPsec: Default to rekey=no
by Michael Tremer 20 May '15

20 May '15

Hi, On Tue, 2015-05-19 at 20:08 +0200, Wolfgang Apolinarski wrote: > Hi! > > I first want to say that I do not like the standard configuration of ipsec in > ipfire, because I am mainly using Windows and Android clients (phone/PC) and > the standard configs just do not work with that. This is why I added some > configuration templates to the ipfire wiki (which are mostly taken from the > Strongswan docu with some added information specific to ipfire). Indeed is it quite complicated to have one generic configuration for both, the net-to-net connections and all roadwarrior connections. We will get in inter-operability hell. Luckily this has become much better with strongswan. > When rekey is set to no, the server does not initiate any rekey, which is > mandatory for Windows, because Windows does not like the server to take the > initiative. Windows clients are initiating the rekey every 58-59 minutes > (according to the strongswan docu, I did not check that in the logs). > > There is (at least one) other alternatives than rekey=no: > Set the lifetime of the child SA to something like 90 minutes. Then Windows > clients initiate the rekey after 58-59 minutes and rekey can be set to yes. > > One could also set rekey=no, but fix the lifetime of the CHILD_SA. The > CHILD_SA is then thrown away and the client needs to rekey (and apparently > does so). If I understand the strongswan docu [1] correctly, the default is > set to 1h (attention to the margin!) and should also be used when rekey=no. So > rekey=no is a safe setting, security wise (someone should test this behavior, > though). I can live with either of those two options. If we find a way that we can kill the connection when the client does not rekey in a certain time that we get rid of the need to rely on the client to rekey. We cannot trust that the client will do this. There is also a related bug over here: https://wiki.strongswan.org/issues/945 This one points out that rekey=no is different for IKEv1 and IKEv2. > If connecting two ipfire devices via ipsec is one of the user scenarios that > should be supported, a default setting of rekey=no might not make sense since > both ipfire devices would not rekey, i.e., the connection would be dropped. A > longer CHILD_SA lifetime could be an alternative. There is no need to have rekey=no for the net-to-net connections. > What is on my whish list: > An option menu when creating a new ipsec vpn connection that offers specific > configurations (Windows 7 (X.509 Machine Auth), Windows Phone (X.509 User Auth > over EAP-TLS), Android (IKEV1, X.509, xauth)). > I did not add this, because of a) time and b) my weird configuration that uses > the ipfire DHCP and ends the tunnel directly in the green network (which - > from what I understood while reading the old documentation - is not the normal > configuration). I too have a very long wishlist with IPsec features. More authentication methods to enhance compatibility with more mobile devices is definitely on the list, but also tough to realise if you do not have a central user management system. > > On Tue, 19 May 2015 18:06:06 +0200, Michael Tremer > > <michael.tremer(a)ipfire.org> wrote: > (...) > > IPsec has always had these woes. That is the main reason why those awful > > SSL VPN solutions exist. > > Yes! :-) > > Cheers, > Wolfgang > > [1] https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey -Michael

1 0

IPsec: Default to rekey=no
by Larsen 20 May '15

20 May '15

Hi, we noticed interruptions with our IPsec roadwarrriors. The problem turned out to be caused by the server trying to rekey with the client that is sitting behind a NAT (Windows 7 client at colleague's home). See https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#Rekeying-beha… This was solved by adding "rekey=no" to "/etc/ipsec.user.conf" for each connection. I wonder if this should be added by IPFire by default as I guess that all roadwarriors behind a NAT (probably the majority) might have this problem. So, adding print CONF "\trekey=no\n"; to /srv/web/ipfire/cgi-bin/vpnmain.cgi Lars

3 4

: AW: IPsec: Include ipsec.user.conf at the bottom
by Heribert Schorn 19 May '15

19 May '15

1 0

Re: AW: IPsec: Include ipsec.user.conf at the bottom
by Larsen 19 May '15

19 May '15

Just stumbled across this in vpnmain.cgi: "/etc/ipsec.user-post.conf" When this file exists, it will be included. So apparently, we were using the wrong file (or the documentation is missing that - I don´t know where my co-worker got it from). Lars On Tue, 19 May 2015 17:07:41 +0200, Heribert Schorn <Schorn(a)t-online.de> wrote: > Hi, > > I agree withe Larsen suggestions to have the include als at the bottom. > With the include stetment on the top the seteetings of ipsec.user.conf > are overwritten and the connection e.g. to IOS or Android will not work > following the proposal in the wiki or the forum. > > regards > Heribert

2 2

IPsec: Include ipsec.user.conf at the bottom
by Larsen 19 May '15

19 May '15

Hi, I noticed that in "/var/ipfire/vpn/ipsec.conf" the line "include /etc/ipsec.user.conf" is placed at the top instead of the bottom. For us, this leads to the problem that our configuration from "ipsec.user.conf" is overwritten by the default configuration from "ipsec.conf" when it should be the other way around. Therefore, after a restart of the IPsec server (iirc), I have to manually fix this problem by moving the line from top to bottom. Is this by design or is this a bug? Using IPFire 2.17 (i586) - Core Update 89 Lars

2 2

boost 1_58_0 - rootfile
by Matthias Fischer 19 May '15

19 May '15

Hi, is there a specific reason for commenting the line ... #usr/lib/libboost_math_c99l.so.1.55.0 ... in rootfile for 'boost 1_55_0'? All other '/usr/lib/libboost*'-files are uncommented, only this one is ~deactivated. This came to me while building an update to 'boost 1_58_0'. Regards Matthias

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Development May 2015