Hallo,
habe heute folgendes festgestellt:
1.) IP-R "Load balancing enabled" ohne Einträge in der Tabelle: Outbound Packets werden ohne NAT auf das WAN Interface geroutet (d.h. 172.16.5.1 (statt Public IP) -> 1.1.1.1), mit Wireshark auf dem WAN Switch gefunden, 3*DSL /32 Public IPs.
2.) Port Forwarding Table, ohne Angabe von "Remote Site": scheint mindestens die Wahrscheinlichkeit gleicher IP Ports beim PATing/NATing zu erhöhen, der Paket Filter des nachgelagerten Reverse Proxies beschwert sich über gleicht Ports und damit verbunden Paket Sequence Errors.
Habe jetzt bei allen Einträgen "Remote site" angegeben, verhält sich wohl mindestes besser, 3*DSL /32 Public IPs.
Es wäre gut, wenn ihr das bei Gelegenheit testen/ausbauen könntet, die Symptome sind sehr unangenehm. Wäre schon, wenn ihr auch ein paar Test mit mehren /32 Adressen (DHCPOE) auf einen Gerät machen könntet, KABLEBW liefert leider nichts anderes, ich habe 5 /32 und versuche diese auch zu nutzen.
Danke und viele Grüße
Henri
2* unerwünschtes Verhalten
Moderator: Lancom-Systems Moderatoren
Re: 2* unerwünschtes Verhalten
Hallo Henri,
Viele Grüße,
Jirka
ohne Einträge in welcher Tabelle? Tritt das Problem immer auf oder nur manchmal? Wie kann ich das nachstellen?Henri hat geschrieben:1.) IP-R "Load balancing enabled" ohne Einträge in der Tabelle: Outbound Packets werden ohne NAT auf das WAN Interface geroutet (d.h. 172.16.5.1 (statt Public IP) -> 1.1.1.1), mit Wireshark auf dem WAN Switch gefunden, 3*DSL /32 Public IPs.
Was ist "Remote Site"? Peer/Gegenstelle oder WAN-Ad(d)ress(e)? Aber selbst wenn ich das wüsste, verstehe ich das Problem noch nicht.Henri hat geschrieben:2.) Port Forwarding Table, ohne Angabe von "Remote Site": scheint mindestens die Wahrscheinlichkeit gleicher IP Ports beim PATing/NATing zu erhöhen, der Paket Filter des nachgelagerten Reverse Proxies beschwert sich über gleicht Ports und damit verbunden Paket Sequence Errors.
Habe jetzt bei allen Einträgen "Remote site" angegeben, verhält sich wohl mindestes besser, 3*DSL /32 Public IPs.
Wenn Du mir, wie schon geschrieben, mitteilst, wie ich dieses Verhalten hin bekomme, dann würde ich das mal testen, ja.Henri hat geschrieben:Es wäre gut, wenn ihr das bei Gelegenheit testen/ausbauen könntet
Viele Grüße,
Jirka
Re: 2* unerwünschtes Verhalten
Hallo Jirka,
danke für Deine Antwort.
Die Verbindung hat dann nicht mehr funktioniert, war reproduzierbar.
Henri
danke für Deine Antwort.
-> "Load Balancing enabled", "Load Balancing" Tabelle leerohne Einträge in welcher Tabelle? Tritt das Problem immer auf oder nur manchmal? Wie kann ich das nachstellen?
Die Verbindung hat dann nicht mehr funktioniert, war reproduzierbar.
Ticket 1602.2010.1633.ACALWas ist "Remote Site"? Peer/Gegenstelle oder WAN-Ad(d)ress(e)? Aber selbst wenn ich das wüsste, verstehe ich das Problem noch nicht.
Danke und viele GrüßeFrom your reply on March 5.
"To do proper outbound NAT (or Inbound NAT) all the devices involved must be able to uniquely identify connections. This is done by looking at source/dest IP and source/dest ports. These remain the same for a connection to be identified. However, we are also tracking the ACK/SEQ numbers in the connection. If this suddenly changes drastically, some other computer behind that NAT is using the exact same source port. This is either an error in the firewall configuration (if it allows you to make such errors) or a bug in that firewall. I would definitely contact the vendor of that firewall with the data you have shared with us and with our replies to you about this."
The 30 second window is because all such uniquely identifiable connections must have a period of time to timeout. You never know how long it might be before another packet is sent over a connection. If we lowered that time say, to 10 seconds, you would likely have a lot of other weird consequences with connections that previously worked very well.
This is described in many places on the Internet.
In a normal NAT firewall, you might have a hundred outbound TCP connections outbound to a single server, and this is fine. On the outside (Internet side) of the firewall, they will simply all have different source ports. The firewall we are pointing at does not. It is using the same source port for 2 different connections. This is also interpreted as not waiting for the 30 second timeout to initiate a new connection using the same CID (Connection Identifer).
"I currently try to get rid of NAT internally, because of some issues in conjunction with the natted IPs. But I need the reverse proxy ( have here about 10 times Port 443, reachable from customer networks ( e.g. Banks)."
Again, NAT should not be a problem (as long as you are not forcing the source port on that firewall somehow.. that would cause this). If you let it automatically determine the source ports when doing NAT, you should not have these problems unless there is a bug in that firewall's firmware.
Henri
Re: 2* unerwünschtes Verhalten
Hallo Henri,
Dann könnte man das wirklich als Bug ansehen, obwohl es ja nicht sauber konfiguriert ist. Ich schaue es mir mal an.
Zu dem anderen Teil: Ich hab's jetzt nur mal überflogen. Bist Du muttersprachlich Englisch sprechend oder warum ist das jetzt auf Englisch?
Viele Grüße,
Jirka
hmm. D. h. Load-Balancing-Tabelle leer, es gibt also keine derartige Gegenstelle und in der Routing-Tabelle wird auch auf keine (nicht existierende) Load-Balancing-Gegenstelle verwiesen?Henri hat geschrieben:-> "Load Balancing enabled", "Load Balancing" Tabelle leer
Dann könnte man das wirklich als Bug ansehen, obwohl es ja nicht sauber konfiguriert ist. Ich schaue es mir mal an.
Zu dem anderen Teil: Ich hab's jetzt nur mal überflogen. Bist Du muttersprachlich Englisch sprechend oder warum ist das jetzt auf Englisch?
Viele Grüße,
Jirka