guess what 
routeros sends out the gre packets out the wrong interface with the wrong src-addr and the tunnel still works (both ADSL lines have the sime provider and one is NATed - thats why the packets sent back to the wrong src-addr get to the same router)
what do you have to say about this ?
its the packet leak problem again 
there are other packets that have the wrong src-addr as well
I have the captures to prove it and everything. Could it become a condition when the load balance router is the pptp client and one line goes down then goes back up ?
Am going to bed will give screenshots tomorrow.
The capture done with Tool ā Sniffer has source IP address of the other interface. Not the one the capture was performed on. It also has some packets with the proper source address. This was also confirmed with Torch. I have this file and Im keeping it to myself for security reasons.
The router load balancing config is this: http://wiki.mikrotik.com/wiki/NetworkPro_on_Combining_NATed_Links - you can see in the wiki that the NAT rule is based on source IPs and not on outgoing interfaces. Previous discussions about āpacket leakageā led to a conclusion that the NAT rule needed to have an outgoing interface. So I added two new NAT rules ONTOP of the other one that were masq-ing based only on outgoing interfaces and NOTHING CHANGED the gre packets (as well as some other packets - some that show as pptp in Wireshark) still had the src-addr of the OTHER ADSL interface.
Note: That the routes are with a nextop set as the interface name: ADSL1, ADSL2 accordingly as per the PCC examples. Could this be the reason why RouterOS does not know what IP address to put on the outgoing packets? Will RouterOS masq the packets with the correct IP if the routes were pointing to a nextop IP address instead of an Interface name? This needs investigation, comparison to other working setups like this oneā¦ etc..
s a screenshot that could make it a bit clearer: SCREENSHOT 80kb gif
Iām interested in this as well as I have seen weirdness like this before and would love to understand it more.
Are you sure its the GRE thats not working properly, or is it the PPPoE traffic thats coming down the wrong port? I guess without seeing the pcap I canāt tell.
I know with cable networks the head end uses the same MAC address, and Mikrotik would see that and just start throwing packets out whatever interface it felt like (with more than 1 cable connection). It also did that on the way back in if I didnāt use 2 completely separate MAC addresses (not same NIC). If you EVER send a single packet with the MAC address of one NIC thru the other port, the far end equipment might learn this MAC/IP association and start sending traffic back the wrong way. Are you sure that ONLY gre is crossing between the NICs, or is ICMP and other protocols as well?
Sam
100% sure its the gre. in the pcap I can see a tcp conversation with googleā¦ that has the correct src addr. All fu(ket up packets are GRE protocol + tcp PPTP port 1723.
This could totally be a problem related to the fact that the PPTP protocol was not established from a clean state when the load balancing PCC config was raedy, but rather - the tunnel was established and I did all the config over this tunnel ā¦
Later on Ill test more when this particular router is online.
Is this this same problem?
Whatās new in 4.2:
*) fixed problem - RB450G ethernet did not work if one of the ports was disabled;
*) fixed ethernet of RB433 with switch chip IP175D;
*) fixed route attribute problem;
*) fixed route next-hops falling under multiple connected routes;
Whoooooooopsieeee
I think I am re-routing a marked connection thats why this phenomenon would occur. I have a mark routing after the PCC rules. I have not looked into it a 100% now, since this was an old issue that was not a real show stopper.
p.s. but I poiinted this out alredy
This could totally be a problem related to the fact that the PPTP protocol was not established from a clean state when the load balancing PCC config was raedy, but rather - the tunnel was established and I did all the config over this tunnel ā¦
So when the NAT starts NAT-ing and then I re-route this same connections - thaāts when this occurs.
I am going to actually take advantage of that particular ISP sending packets with not-his-own source addresses. Bwahahaha (devil).
