Securepoint Support Forum

No

Configuration file sent via YouSendIt.com to support@securepoint.de
You should have received the email by now.

Alternatively do you have a direct email address you can tell me via PM.
Cheers, Andy

Hello, have you received this yet? If not, can you maybe send me a PM or email me your email address as there must be spam blocking happening somewhere.
Cheers, Andy.

Yes

Hi,

there is configured a routing timeout of 5 minutes. If a connection reach this value the routing engine will make a new routing decision by random.

You can change this value(changes it to 10 minutes):

"change kernelparameter net.ipv4.route.gc_timeout 600"

Please be aware of changing this value can cause unknown errors!! Try to increase this value slowly! The changing will effect immediatly.

Hello, Thank you very much. I will give this a try.
Will this change be persistent over reboots if I save the configuration after running the above command?

Yes, If you save your config the changes will be permanent

Changing kernel paramter is a new feature in R3

Hello, is there an upper limit on this value?

It seems to help a bit if it is kept to no more than '999' seconds, above that and it seems to revert back to the default timeout. The problem is still quite evident

PS; If I set it the value to '999' the sessions die quicker than this value (E.g. An unused PPTP connection dies after about 8 minutes (480) and not 999).

Thank you for your time and help. Andy.

After some further investigations I can confirm that modifying this timeout value does not fix the issue as the routing path is changing before the idle timeout, even once the session is established and traffic is being sent constantly the path is changed randomly and the session is broken.

Hello, is it possible to change my Hide NAT (Dynamic NAT) on my external interfaces to use static NAT instead becuase my external interfaces all have static IPs?

For example;
Can i set it so, the whole LAN (Internal Network) when going out of the EDGE1/WAN1 interface is always static masqueraded to an IP within the EDGE1 network.
Can i also set it so, the whole LAN (Internal Network) when going out of the EDGE2/WAN2 interface is always staticly masqueraded to an IP within the EDGE2 network.
Can i also set it so, the whole LAN (Internal Network) when going out of the AlwaysOn interface is always staticaly masqueraded to an IP within the AlwaysOn network.
And so on....

The reason I would like to try this is becuase this dieing session problem is due to a bug with dynamic/hide NAT.
http://linux.derkeiler.com/Newsgroups/c ... 00092.html
http://www.mail-archive.com/lartc@mailm ... 15079.html

If external IPs are static, you can do the following;
EDGE1 interface IP = 192.168.214.2
EDGE2 interface IP = 192.168.215.2
AlwaysOn interface IP = 192.168.175.1
ISDN interface IP = 192.168.2.2

iptables -t nat -A POSTROUTING -o EDGE1 -j SNAT --to 192.168.214.2
iptables -t nat -A POSTROUTING -o EDGE2 -j SNAT --to 192.168.215.2
iptables -t nat -A POSTROUTING -o AlwaysOn -j SNAT --to 192.168.175.1
iptables -t nat -A POSTROUTING -o ISDN -j SNAT --to 192.168.2.2

NB: Internal Network = 192.168.200.0/24, eth7

Better;
iptables -t nat -A POSTROUTING -s 192.168.200.0/24 -o eth2 -j SNAT --to 192.168.214.2
iptables -t nat -A POSTROUTING -s 192.168.200.0/24 -o eth3 -j SNAT --to 192.168.215.2
iptables -t nat -A POSTROUTING -s 192.168.200.0/24 -o eth1 -j SNAT --to 192.168.175.1
iptables -t nat -A POSTROUTING -s 192.168.200.0/24 -o eth5 -j SNAT --to 192.168.2.2

This would fix the problem, however it would be even better if it could be fixed to work with normal dynamic NAT.

Thank you for all your time and effort on this

Hallo Oliver, ich danke Ihnen für Ihre schnelle Antwort der letzten Woche.

Benutzen Sie Ihre Beratungs-und 'iptables-t nat - list-v' konnte ich meine NAT'ing konfiguriert und funktioniert. Wir sind mit Mehrwegeausbreitung mit NAT für ausgehende Schnittstellen.


Allerdings war ich noch Probleme mit Sessions fallengelassen werden aufgrund der Multipath-Routing-Entscheidungen verändert, wenn die Route-Cache geleert wurde.
Ich konnte sehen, dass die Sitzungen starb, sobald die IP-Route zeigen, cache 'berichtet, hatte die Route geändert. Dieses Problem ist ein Ergebnis von Securepoint nicht in einer Weise statefull.



FIX: Implementierung von statefull Packet Inspection;

Das erste Paket der jede Verbindung geroutet wird durch die Multipath-Routing. Dies geschieht nach der PREROUTING, wie Sie wissen. Und das ist das, was wir wollen, Vermietung der Kernel entscheiden auf der Grundlage der Gewichte.
Dieses Paket kann dann markiert POSTROUTING (so dass die lokalen Pakete können auch gefangen werden). Markieren Sie es und speichern Sie sie.
Die Marke ist decodiert die gewählte abgehende Schnittstelle (zB:-o WAN1 - gesetzte Markierung 1,-o Wan2 - set-mark 2).

In PREROUTING können wir dann mit 'Wiederherstellen-Marke ". Wenn das Paket gehört zu einer Verbindung, die bereits ein Paket verschickt, so wird die Marke wieder in POSTROUTING und wird dann geroutet werden durch die entsprechenden Routing-Tabelle.
Handelt es sich um ein neues Paket, es wird dann von der Multipath-Routing-Anweisungen, da keine Marke vorhanden ist, usw.


Ich setzte die nachfolgenden als 'root';
# iptables-A POSTROUTING-t mangle-j MARK - set-mark 1-m state - Zustand NEU-o eth0
# iptables-A POSTROUTING-t mangle-j MARK - set-mark 2-m state - Zustand NEU-o eth2
# iptables-A POSTROUTING-t mangle-j CONNMARK - save-mark-m state - Zustand NEU

# iptables-A PREROUTING-t mangle-j CONNMARK - wiederherstellen-Marke

Route folgenden Pakete basieren auf der restaurierten Marke

# ip-Regel hinzufügen fwmark 1-Lookup 1
# ip add fwmark Regel 2-Lookup 2

# iptables-A POSTROUTING-t nat-m-Marke - Marke 1-j SNAT - to-source 11.1.1.1-o eth0
# iptables-A POSTROUTING-t nat-m-Marke - Marke 2-j SNAT - to-source 22.2.2.2-o eth2



Nach dem Ausführen der oben genannten Befehle zu ermöglichen, SPI (Statefull Packet Inspection) das Problem der sterbenden sesisons festgesetzt worden war und Verbindungen nicht sterben nach einigen Stunden des Testens.

Doch nach der Umsetzung dieses Update nur die Probleme gefunden wurden;
Port 80 (http) würde nicht funktionieren, es sei denn, squid wurde aktiviert.
Port 443 (https) würde nicht funktionieren überhaupt.

Wie können wir dauerhaft aktivieren SPI in securepoint, und wie kann ich dieses Problem beheben der Port 80 und 443?
Auch wissen Sie, wenn alle anderen Häfen sind affted ähnlich Ports 80 und 443?

Referenz:
http://imbezol.org/loadbalance.php
http://www.realvnc.com/pipermail/vnc-li ... 49651.html

---------------------------

Hello Oliver, thank you for your quick reply last week.

Using your advice and 'iptables -t nat --list -v' I was able to get my NAT'ing configured and working properly. We are using multipath with NAT on outbound interfaces.


However I was still having problems with sessions being dropped due to the multipath routing decisions changing when the route cache was flushed.
I could see that the sessions died as soon as 'ip show route cache' reported the route had changed. This problem is a result of Securepoint not operating in a statefull manner.



FIX: Implement statefull packet inspection;

The first packet of any connection gets routed by the multipath routing. This happens after PREROUTING, as you know. And this is what we want, letting the kernel decide based on the weights.
This packet can then be marked in POSTROUTING (so that local packets also can be caught). Mark it and save it.
The mark is decoded by the chosen outgoing interface (eg: -o WAN1 --set mark 1, -o WAN2 --set-mark 2).

In PREROUTING we can then use 'restore-mark'. If the packet belongs to a connection that has already sent a packet, this will restore the mark set in POSTROUTING and will then be routed by the corresponding routing table.
If it is a new packet, it will be routed by the multipath routing statements since no mark exists, etc.


I implemented the folling as 'root';
#iptables -A POSTROUTING -t mangle -j MARK --set-mark 1 -m state --state NEW -o eth0
#iptables -A POSTROUTING -t mangle -j MARK --set-mark 2 -m state --state NEW -o eth2
#iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark -m state --state NEW

#iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark

Route following packets based on the restored mark

#ip rule add fwmark 1 lookup 1
#ip rule add fwmark 2 lookup 2

#iptables -A POSTROUTING -t nat -m mark --mark 1 -j SNAT --to-source 11.1.1.1 -o eth0
#iptables -A POSTROUTING -t nat -m mark --mark 2 -j SNAT --to-source 22.2.2.2 -o eth2



After running the above commands to enable SPI (Statefull Packet Inspection) the problem of dieing sesisons was fixed and connections did not die after several hours of testing.

However, after implementing this fix the only problems found were;
port 80 (http) would not work unless squid was enabled.
port 443 (https) would not work at all.

How can we permanently enable SPI in securepoint and how can i fix the port 80 and 443 issue?
Also do you know if any other ports are affted similar to ports 80 and 443?

Ref:
http://imbezol.org/loadbalance.php
http://www.realvnc.com/pipermail/vnc-li ... 49651.html

After lots of head scratching and lots of help from the Securepoint guys we have now been able to completely fix this and even enhance Securepoint.

Previously Securepoint operated as a stateless firewall. This means that every packet the firewall processed was treated individually.

-----------------------------------

Nach viel Kopf kratzen und viel Hilfe von der Securepoint Jungs haben wir jetzt in der Lage, vollständig dieses Problem beheben und sogar Verbesserung der Securepoint.

Zuvor Securepoint betrieben als Staatenlose Firewall. Dies bedeutet, dass jedes Paket die Firewall verarbeitet wurde individuell behandelt.

Das Problem war ich erleben, war ein Ergebnis dieser Operation Staatenlosen und die dynamische Natur der multi-path-Routing.

Durch die Ermöglichung einer einfachen Schicht 3 Stateful Packet Inspection, Securepoint jetzt Tracks Pakete und somit ist in der Lage ist, eine dynamische Pfade auf einer Grundlage pro Sitzung.
http://en.wikipedia.org/wiki/Stateful_firewall

Um ein Update auf die neueste Entwicklung bauen, die diese Funktion;
Login mit ssh mit "admin" Benutzernamen.
laufen; "Update Firewall aktuellen"

The problem I was experiencing was a result of this stateless operation and the dynamic nature of multi-path routing.

By enabling simple layer 3 Stateful Packet Inspection, Securepoint now tracks packets and thus is able to maintain a dynamic paths on a per session basis.
http://en.wikipedia.org/wiki/Stateful_firewall

To update to the latest development build which includes this feature;
login with ssh using 'admin' user name.
run; 'update firewall current'

Oops, missed some text!

After lots of head scratching and lots of help from the Securepoint guys we have now been able to completely fix this and even enhance Securepoint.

Previously Securepoint operated as a stateless firewall. This means that every packet the firewall processed was treated individually.

The problem I was experiencing was a result of this stateless operation and the dynamic nature of multi-path routing.

By enabling simple layer 3 Stateful Packet Inspection, Securepoint now tracks packets and thus is able to maintain a dynamic paths on a per session basis.
http://en.wikipedia.org/wiki/Stateful_firewall

To update to the latest development build which includes this feature;
login with ssh using 'admin' user name.
run; 'update firewall current'