I follow this guide step by step to stage “Incoming connectios done”
All is working, I can browse a web page from the mainISP and cameras web from the backupISP
All Lan traffic is going out to mainISP because I dont setup outgoing from our lan to the internet and it is using default gateway
I have setup L2TP vpn clients and they are workin with the mainISP.
Now when I setup a vpn client for the backupISP, the client is workin much unstable.
I think i have a concept mistake, at this point i konw that when a connection is initiated from the internet through one of the ISPs I ensure that this connection is replied through the same ISP, but somithing is wrong because vpn connecctions comming from backupISP is not working but connecctions to the cameras web comming from the same backupISP is workin.
here is some more detail.
. I only want taking care of incoming connections from MAIN and BKP isp, if wan incoming come from MAIN must return to MAIN and the same for BKP
. I do not want Load Balancing
. LAN → WAN traffic go out to MAIN isp.
I have problems with VPN connections.
If a VPN connection come from MAIN it must return to MAIN, this is working (i suppodes becouse it is the default route), but if come from BKP it must return to BKP and it is not working
I believe that i having problems with Fasttrack and IPSec, i read that there are some issues.
But for now i have not found the solution and my mangle is still not working on the second ISP
Fasttracking is only used in the forward chain, and L2TP transport packets are handled by input and output chains, not the forward one.
Your mangle rules seem fine for the L2TP session to get established, except if the L2TP client connects from 888.888.888.0/24 or 999.999.999.0/24. Are you testing from one of these subnets or from a totally unrelated one?
Does the L2TP client connect successfully, but no traffic is getting through the established tunnel, or does already the L2TP connection of the client fail?
Are you testing from one of these subnets or from a totally unrelated one?
totally different
Does the L2TP client connect successfully, but no traffic is getting through the established tunnel, or does already the L2TP connection of the client fail?
from main ISP (888.888.888.0 and default route) L2TP clients are working
from second ISP (999.999.999.0) L2TP clients connects but suddenly disconect
How long after connection establishment this happens? Seconds, hours? If it works for a minute and then fails, the root cause may not be related to the policy routing (mangle rules etc.) at all.
How long after connection establishment this happens? Seconds, hours? If it works for a minute and then fails, the root cause may not be related to the policy routing (mangle rules etc.) at all.
yes, ma-by the backup ISP because sometimes the connection break at the moment and anthers work by hours, but still there is some problem that i can understand.
i have a webserver running that is accessible from wan by this nat
10.0.41.19 is haproxy that redirect traffic to the final webserver 10.0.41.10
from mainISP (default route) is workink OK, but from backupISP is don’t working.
I know that when the package leave the router mangle marks are cleaned, then how know the response from the webserver that must go out to backupISP and not by default gateway?
This is what connection-mark is used for - it is assigned to the connection as a whole when one of the first packets belonging to that connection is processed, and then all packets belonging to the same connection get this connection-mark as they pass through the connection tracking module of the firewall, as one of the first stages of processing (only raw rules are examined before connection tracking). So in your particular case, the action=mark-connection rule matches on the first SYN packet from the client and assigns the connection-mark value, and then the action=mark-routing rule matches on all the packets sent by the server and belonging to the same connection.
I cannot see anything wrong about your mangle rules, so you have to run a sniffer to see what is going on. The address of the client doesn’t change as the packet passes through the various stages of firewall handling, so make a command line window as wide as your screen allows and run /tool sniffer quick ip-address=ip-of-the-client while attempting to connect from a remote client via the backup WAN, to see whether the requests arrive at all (some ISPs block incoming traffic to server ports) and whether the responses from the server come from the expected address (of the ha-proxy) and port.