http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35263 What games are you playing? I'm running 1.235 and have never set up any forwarding to my Wii, and I don't have any problems "hosting" in Mario Kart or Guitar Hero. I had assumed that the Wii connected to Nintendo's WFC servers and all the communication happened there, rather than the PC games style of having other players actually connecting to your PC. When I have had problems, I would get disconnected after a minute or two of a kart race, but we would see similar issues regardless of who first opened the room. I guess I don't really have any useful suggestions or information here. I'm sure there are other Wii owners on multiple firmware versions to chime in. I have some spare hardware here and may try installing 1.3 over the weekend to see if I get different results than 1.2. -Tim On Dec 3, 2008, at 7:02 PM, Christopher M. Iarocci wrote: Tim Kingman 2008-12-04T01:51:33 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35262 I have a WII behind my m0n0wall at home. I'm running 1.3B15. I am unable to host a room on the WII. I can connect to a hosted room without issue. I found the ports used to host a game and port forwarded them to my WII. However, even though they are not being blocked (checked the logs), the connection still does not happen. So, I dropped a Linksys in place, bam, hosting works fine. So I did a bit more experimenting with the m0n0wall (borrowed a friend's WII and connected them both). If I do a 1:1 NAT mapping to the WII from my outside IP and open the firewall ports, everything works fine. If I simply port forward the ports and open the firewall, it will not work. So my question here is, what is the major difference between port forwarding and 1:1, and is there a way to get around this problem? I would love to leave the 1:1 in place, but unfortunately I only have a single IP and other services that run behind it that get broken when the 1:1 is in place. Thanks for any help you can off Christopher M. Iarocci 2008-12-04T00:02:30 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35261 I think it's only a problem with SAD and SPD rules. If I could change SAD and SPD from 10.0.0.1 (OPT IP) to my own value maybe it works?!? Any idea? Have many thanks! Michael -----Ursprüngliche Nachricht----- Von: Michael Stecher [mailto:Michael.Stecher< at >cib.de] Gesendet: Mittwoch, 3. Dezember 2008 09:23 An: m0n0wall< at >lists.m0n0.ch Betreff: AW: AW: [m0n0wall] Problems with IPSec Site to Site Tunnel: ignore RESPONDER-LIFETIME notification OK, have many thanks for your help. Is there another reason to use m0n0wall with different VPN subnets? I don't want to install a m0n0wall for each net. ---> IPSec Tunnel 1 / 10.1.1.1/29 WAN -> m0n0wall OPT (10.0.0.0/8) --- ---> IPSec Tunnel 2 / 10.1.1.9/29 Bye, Michael -----Ursprüngliche Nachricht----- Von: Chris Buechler [mailto:cbuechler< at >gmail.com] Gesendet: Freitag, 28. November 2008 17:26 Cc: m0n0wall< at >lists.m0n0.ch Betreff: Re: AW: [m0n0wall] Problems with IPSec Site Michael Stecher 2008-12-03T16:00:13 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35260 Perfect! Glad you got it working! Sometimes, the onboard flash/CF readers weren't meant for booting but rather for non-volatile storage of configs/etc... Maybe that's the case with your Symantec unit. Either way, enjoy your m0n0! Tim Nelson Systems/Network Support Rockbochs Inc. (218)727-4332 x105 ----- "Daniel Ekman" <daniel< at >33k.org> wrote: Tim Nelson 2008-12-03T15:54:33 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35259 Hi Tim There is accually a cf slot on the motherboard and all cmos and bios settings has been cleared, just found a ide -> cf adapter and that worked like a charm. so its only the onboard cf reader that produce the problem, but i can live with the ide -> cf adapter really. thanks :) /Daniel ----- Original Message ----- From: Tim Nelson [mailto:tnelson< at >rockbochs.com] To: Daniel Ekman [mailto:daniel< at >33k.org] Sent: Wed, 03 Dec 2008 16:08:59 +0100 Subject: Re: [m0n0wall] problems during reboot on cf 3 3 x . b e t /rot ther'teen/ [Usenet: from "rotate alphabet 13 places"] Daniel Ekman 2008-12-03T15:34:19 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35258 I've done a great deal of "hardware repurposing" with both monowall and pfsense on everything from Watchguard firewalls, Intel SSL accelerators, Nokia firewalls, etc... Most of the time they're simply standard x86 hardware underneath with a pretty chassis wrapped around it to make sure you pay more :-). In my experience, it's best to first clear the BIOS of any factory settings and start fresh. Disabling ACPI helps with some disks as well. Also, check the usual suspects like power supply, cabling, CF card, CF reader, etc. Speaking CF reader, what type are you using? I'm assuming a standard 40pin IDE-CF adapter? All optimism aside, I've sometimes found that hardware appliances are simply too customized or modified to be used with something different and it simply won't work. BUT, we'll leave that thought alone until all other options are exhausted. :-) Tim Nelson Systems/Network Support Rockbochs Inc. (218)727-4332 x105 ----- "Daniel Ekman" <daniel< at >33k.org> wrote: Tim Nelson 2008-12-03T15:13:54 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35257 Hi First let me clearify that this most likely has nothing at all to do with the actual m0n0wall software. I work as a system consultant and have come across several different hardware that no longer are supported by the vendor itself, end of life or whatever. last mission have been to install m0n0wall on Symantec Gataway Security 5420 but with a compact flash instead of the shipped ~40gb disk. everything has been set up and works fine until a reboot of m0n0wall, the first bootup works without problems and i can configure the system no problem. but after the first reboot of the system it is unable to mount and find the config xml, the acual system boot but is unable to locate that file and halts, i get the option to press any key to reboot so i do. after that the hardware cant find the compact flash at all. after a "hard reset" of the system everything is fine again and all previous setting before the reboot is applied and great. this ofcourse leeds me to believe theres some hardware lock/config/somethin Daniel Ekman 2008-12-03T14:59:52 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35256 OK, have many thanks for your help. Is there another reason to use m0n0wall with different VPN subnets? I don't want to install a m0n0wall for each net. ---> IPSec Tunnel 1 / 10.1.1.1/29 WAN -> m0n0wall OPT (10.0.0.0/8) --- ---> IPSec Tunnel 2 / 10.1.1.9/29 Bye, Michael -----Ursprüngliche Nachricht----- Von: Chris Buechler [mailto:cbuechler< at >gmail.com] Gesendet: Freitag, 28. November 2008 17:26 Cc: m0n0wall< at >lists.m0n0.ch Betreff: Re: AW: [m0n0wall] Problems with IPSec Site to Site Tunnel: ignore RESPONDER-LIFETIME notification On Fri, Nov 28, 2008 at 11:05 AM, Michael Stecher <Michael.Stecher< at >cib.de> wrote: That's just to allow the connections to be initiated. Add rules in the GUI for anything else you need to pass. m0n0wall won't listen on proxy ARP IPs so you can't terminate IPsec connections using one. --------------------------------------------------------------------- To unsubscribe, e-mail: m0n0wall-un Michael Stecher 2008-12-03T08:22:59 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35255 Hi, Yet another post on this bug! In message <iFuwxBC7rrMJFwrt< at >dana.internal.dana.org.uk>, Neil A. Hillard <m0n0< at >dana.org.uk> writes I've done a fairly un-scientific test on all of the 1.3 beta releases! I can report that this NAT bug appears to affect 1.3b1 thru 1.3b15 so it looks to be a FreeBSD 6.2/6.3 bug! My testing consisted of accessing one specific web site with and without the advanced NAT enabled and measuring the total time to load the page. With advanced NAT enabled, page load times ranged from 13 to 47 seconds whereas with advanced NAT disabled page load times were 2 to 7 seconds! Quite a difference! The testing with the NAT rule was performed with a single NAT rule that had a target of 'NOT 192.168.0.0/24' which should always hit as I've not got a 192.168.0.0/24 network connected to the m0n0wall! I'd love to go back to 1.235 to improve performance but I need to be able to filter the ipsec connection! Is there any way of doing this with 1.235? Many thanks in advance, Neil. Neil A. Hillard 2008-12-03T00:54:13 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35254 Manuel or another dev can probably comment on this further in terms of specific writes... BUT, I can comment on real world usage. Nearly every flash device comes with a wear-leveling mechanism to prevent single-flash-sector burnout from happening as quickly. I've got a few installations of m0n0wall and pfSense on 256MB Sandisk CF cards that have been working flawlessly for nearly two years with semi-regular monthly changes/updates. One of my personal systems at home is using a similar card and has been working for the same amount of time but with constant (almost daily) updates, reflashes, etc. Tim Nelson Systems/Network Support Rockbochs Inc. (218)727-4332 x105 ----- "Holger Rodriguez" <m0n0wall< at >roseng.ch> wrote: Tim Nelson 2008-12-01T17:10:00 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35253 That is it. Only on config changes and firmware upgrades. While running, it is not even mounted. Only reads on boot enough to load into ram. Lee Lee Sharp 2008-12-01T17:07:33 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35252 Hi list, I have a net45xx board and my question is: How often is the card written to in normal operation? I understand, that the events: - upgrade software - changes rules needs writing. I am just curious, because I do want to loose the industrial CF card too early ;-) Cheers, Holger Holger Rodriguez 2008-12-01T17:02:26 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35251 Hi, In message <0vDVruFdGgIJFwaN< at >dana.internal.dana.org.uk>, Neil A. Hillard <m0n0< at >dana.org.uk> writes Does anyone have any ideas on this? I've done lots of searching for FreeBSD bugs relating to this particular problem and can't find anything! This bug is really killing Internet performance and I can't go back to 1.235 because I need to filter incoming ipsec connections! Any advice would be seriously appreciated! Many thanks in advance, Neil. Neil A. Hillard 2008-11-30T16:10:35 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35250 On Fri, Nov 28, 2008 at 11:05 AM, Michael Stecher <Michael.Stecher< at >cib.de> wrote: That's just to allow the connections to be initiated. Add rules in the GUI for anything else you need to pass. m0n0wall won't listen on proxy ARP IPs so you can't terminate IPsec connections using one. Chris Buechler 2008-11-28T16:25:43 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35249 I've found out the problem: we're using a 10.0.0.0 Class A net on m0n0wall OPT interface (endpoint of the tunnel) but only a /29 subnet for the ipsec tunnel. For each subnet we've got one proxy ARP entry in m0n0wall configuration for the respective subnets gateway. In the near future we want to establish more of these subnets with a own ipsec tunnel to a specific customer so it's not possible to use current ipsec subnet for OPT interface. The subnets should be separated from each other (we do this with firewall rules and managed switches). M0n0wall adds ipsec firewall rules for OPT interface IP address (/32), but not for the specific tunnels. ... < at >18 pass out quick on vr2 proto udp from 10.0.0.1/32 port = isakmp to any keep frags < at >19 pass out quick on vr2 proto udp from 10.0.0.1/32 port = sae-urn to any keep frags < at >20 pass out quick on vr2 proto esp from 10.0.0.1/32 to any keep frags < at >21 pass out quick on vr2 proto ah from 10.0.0.1/32 to any keep frags ... < at >32 pass in quick on vr2 proto udp from an Michael Stecher 2008-11-28T16:05:48 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35248 If you are telling me (looking at the timestamp on that dev-list entry) that I sent you my report the SAME day it was fixed and reported back to the dev list, then yes - That IS a coincidence. I noticed this and pretty much immediately reported it today. :) Cheers & keep up the great work! -- Bill Arlofski Reverse Polarity, LLC mtnbkr 2008-11-27T06:22:46 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35247 Hi, draft-ietf-ipsec-nat-t-ike-07... The RFC 3947 was published in January 2005 and it is the reference document. The firmware of the Cisco does not implement it. Anyway, that is details. There are no big difference between this draft and the RFC. I think the remote gateway dropped the response from the racoon. You should take a look to the Cisco logs. I do not like racoon logs because some basic information are missing. In main mode you have 6 exchanges and in Quick Mode 3 exchanges. You can deduce very easily configuration error from the point at which the negotiation failed. In this log, a packet is retransmitted in phase 1, but which one ? Packet with Security Association payload (1rst and 2nd exchanges) ? Or packet with ID payload (5th and 6th exchanges) ? Is there a problem when using UDP port 4500 in the 5th and 6th exchanges ? I do not think it is a configuration issue, because it worked. Cisco logs will be helpful. Regards. - Éric Eric Boudrand 2008-11-26T22:11:55 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35246 Have a look at this: <http://m0n0.ch/wall/list-dev/showmsg.php?id=25/61> Coincidence! :) - Manuel Manuel Kasper 2008-11-26T17:59:36 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35245 Manuel... Not a high priority in the grand scheme of things, but I just noticed a minor issue in the output of the "System: Group Manager" page. It looks like text from somewhere else is being pulled in for the "Description" column for the "Firewall Rules" and "Firewall Rules Edit" lines: --[snip]-- Firewall: Traffic shaper: Queues firewall_shaper_queues.php Firewall: Traffic shaper: Rules firewall_shaper.php Firewall: ipv6enabled( firewall_rules.php Firewall: ipv6enabled( firewall_rules_edit.php Hidden: Detailed Status status.php Hidden: Exec exec.php --[snip]-- The same symptom exists for the "System Routes" and "System Routes Edit" lines: --[snip]-- System: Group manager system_groupmanager.php System: ipv6enabled( system_routes_edit.php System: ipv6enabled( system_routes.php VPN: IPsec: CAs vpn_ipsec_ca.php VPN: IPsec: Edit CA certificate vpn_ipsec_ca_edit.php --[snip]-- This is on 1.3b15, I have not looked elsewhere. Cheers! -- Bill Arlofski Reverse Polarity, LLC mtnbkr 2008-11-26T15:30:47 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35244 Hello Eric, you can find my logs in separated mail to mailinglist. This is our first tunnel between m0n0wall and cisco. We've got some stable tunnels between some m0n0walls on other hardware without any problems. I think we can send IKE und ESP. The peer told me that ESP, UDP 500 and UDP 4500 is opened for us. Have many thanks. Kind regards, Michael (133) -----Ursprüngliche Nachricht----- Von: Eric Boudrand [mailto:eric< at >boudrand.net] Gesendet: Mittwoch, 26. November 2008 10:24 An: m0n0wall< at >lists.m0n0.ch Betreff: Re: [m0n0wall] Problems with IPSec Site to Site Tunnel: ignore RESPONDER-LIFETIME notification Hello, What do you have in the logs ? You can't send IKE packets or ESP packets ? You can find details about this notification in RFC 2407 section 4.5.4. RESPONDER-LIFETIME notification is sent by the responder (that is the Cisco) when "the initiator offers an SA lifetime longer than the responder is willing to accept". The raccon is ignoring the fact the Cisco Michael Stecher 2008-11-26T10:26:15 http://permalink.gmane.org/gmane.comp.security.firewalls.m0n0wall/35243 Hello! I've checked the lifetime settings again and anything seems to be ok. The peer admin told me that now the correct lifetime is transmitted and their cisco will also handle shorter lifetime cycles. So maybe the problem is not the lifecycle?!? I've made some other detection: if the peer side starts the tunnel first I've got following log entry: Nov 26 10:26:48 racoon: NOTIFY: the packet is retransmitted by x.x.x.x[500]. Nov 26 10:26:38 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 Nov 26 10:26:38 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03 Nov 26 10:26:38 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07 Nov 26 10:26:38 racoon: INFO: begin Identity Protection mode. Nov 26 10:26:38 racoon: INFO: respond new phase 1 negotiation: x.x.x.x[500]<=>x.x.x.x[500] It look like the peer didn't receive a needed packet from our side, right? Here is the complete log. Successful start on 09:05, problems on 09:54, try to reconnect from per on 10:26 and restart tunn Michael Stecher 2008-11-26T10:22:33 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.security.firewalls.m0n0wall