Firewall Connection Remove seems broken again v3.15, v3.16

dsdee · Tue Nov 04, 2008 1:58 pm

Both in WinBox and via the command line, I am no longer able to remove active connections, receiving an error:

MikroTik> /ip firewall connection
MikroTik> print
(output snipped)
MikroTik> remove 120,121
action failed(6)

the similar corresponding pop-up happens when I try to remove a connection in winbox. example:

Couldn't remove Connection <192.168.200.8:3897 -> 64.12.x.x.5190> - action failed (6)

This is on a new RB493 with v3.15 installed

Anyone experiencing similar issues? My scripts that worked fine under 3.13 are now broken.

Thanks,

Tue Nov 04, 2008 2:08 pm

Why do you need to remove connections??

dsdee · Tue Nov 04, 2008 2:40 pm

There are cases when I need to remove connections from the connection table that are active in the connection table, but no longer functionally active because routing has changed.

This function has worked well, with only a few hiccups, back into the 2.9 versions of the code.

Clearly the "action failed (6)" is a problem.

dsdee · Wed Nov 05, 2008 5:29 pm

I upgraded to v3.16 this morning, and am still experiencing the "action failed (6)" error on trying to click [-] when trying to remove a connection.

Anyone else?

dsdee · Fri Dec 05, 2008 5:26 pm

I see that v3.17 is out today.

If someone has upgraded already to 3.17, can they verify, please, if "/ip firewall connection remove ###" works, or does not?

(or, the equivalent command in Winbox -- Firewall/Connection tab, then click right and delete a connection) ??

Thanks in advance,
David

dsdee · Wed Jan 14, 2009 4:47 pm

I see that v3.18 is out, but I can't upgrade for at least another week.

Can someone who has upgraded an RB493 to 3.18 confirm whether or not that the "/ip firewall connection remove ###" problem has been fixed, or not ??

Thanks,

Thu Jan 15, 2009 12:12 pm

It doesn't work there either, I will check the bug status

dsdee · Thu Jan 15, 2009 9:07 pm

Fantastic

In response to my 3rd time (3.15, 3.16, 3.17) asking Mikrotik support about it in early December, they told me:

Hello,

Currently connection removing is broken on big-endian platforms such as RB400
series and RB333.RB600 and RB1000. 
This fix will be available in next RouterOS release.

Regards,
Maris

I figured they could've fixed it in that month....

Tue Jan 20, 2009 12:37 pm

From mine point of view this fix is so minor that it doesn't really matters. If my conntrack is getting too full i just reduce timeout values for problematic entries.

And I still don't understand why it is necessary to delete one single connection.

While you still have space for new entries it doesn't matter how much entries are there.
And in case connection tracking is full - everything can be solved by timeout reduction, but it is very rare situation

Tue Jan 20, 2009 12:48 pm

BTW - by deleting connection entries in conntrack you will not stop packet flow.
Only thing that will happen instead of connection-state=established connection tracking will recognize furder TCP packets as connection-state=invalid

For all other IP protocols next packet will recreate deleted entree back.

SO again this feature is pointless. MT should get rid of that command/button at all.

dsdee · Tue Jan 20, 2009 2:07 pm

New connections will indeed be created as-needed

What I need is for certain long-term connections to end-immediately, so that they can be re-routed.

I have two internet connections, different ISPs, and when one fails or becomes unresponsive, I need the connection-oriented traffic that is passing over the now-dead one to be routed over the backup network.

Regardless of whether you think I need it or not, it is a functionality that is built into the OS that does not work... The commands are there, the winbox buttons are there, and it is clearly broken, and needs to be fixed.

I will try it again with 3.19 this weekend when I am back in town, and hopefully it's been fixed...

Tue Jan 20, 2009 2:28 pm

Yes, exactly the same scenario - I use netwatch and script that disables and enables (in simple terms - restarts) connection tracking as soon as gateway goes down (or up).

This is necessary only in case you use NAT.

dsdee · Tue Jan 20, 2009 3:10 pm

ok, and i have (probably similar) scripts that watch the interface, the next-hop gateway, and the dhcp-rewnewal state to make the decision when to fail over or nto.

But for me, I cannot restart all of connection tracking, because not _all_ connections traversomg the router are going thru the now "down" interface --- I have connections that go across the router internally from one VLAN or network to another, and I have connections that go thru the router to the _other_ outside interface (the one that I would be failing over to). If I stop/start connection tracking, then that connection-tracking data would be lost, and any established connections thru the non-failed interface would now fail. They are "held in place" by the "allow established connection" rules, but if all data in the connection tracking table was lost due to cycling the connection-tracker, then all those packets would then be 'new connections' and would not necessarily have the pre-requesites to be rebuilt.

The simplest example would be a TCP connection that is marked as 'established' -- those consist of only the ACk bit being set, obviously. If I clear the connection and a packet comes in with only the ACK bit being set, and its not already "established" then its considered a malformed packet, because it is a connection that is "new" that doesn't have SYN (and not also ACK) set.

Simply, the '/ip firewall connection remove' needs to be working...

Tue Jan 20, 2009 3:35 pm

Sry, but i think there is a misunderstanding here:

your setup will work even without the connection tracking.

By disabling connection tracking you only disable IP firewall (nat, mangle, filter) and queues. Those are facilities connection tracking is used for.

So if your firewall have nothing to do with specific traffic it will go thought the router one way or other.

dsdee · Tue Jan 20, 2009 3:49 pm

No, I don't have a misunderstanding.

I have two natted connections for my external communications.

If I disable connection tracking, then the connection that is "still" working will no longer be "work" and I will lose all those working connections...

as well as the "broken" connections thru the interface that can't pass traffic any longer.

When I need to clear connections, i only need to be clearing the connections thru one interface.

changeip · Tue Jan 20, 2009 9:21 pm

I agree, the remove needs to be fixed. There are times when a connection has to be removed because its going out the wrong gateway with the wrong ip... I've witnessed this enough times myself when swapping gateways.

You need to email support at mikrotik for this one, no one here can fix it : ) It is nice to have this thread so we know when it is fixed however.

Wed Jan 21, 2009 10:59 am

there is a bug ticket opened for this one already. by the way, remove [find] works

NetworkPro · Thu Jan 22, 2009 3:06 pm

I agree, the remove needs to be fixed. There are times when a connection has to be removed because its going out the wrong gateway with the wrong ip... I've witnessed this enough times myself when swapping gateways.

You need to email support at mikrotik for this one, no one here can fix it : ) It is nice to have this thread so we know when it is fixed however.

It seems to me that MikroTik can solve all problems for us by improving on load balancing and failover support in RouterOS. From what I've seen last 5+ years, I am starting to think that MikroTik Latvia need to hire more people because there is too much work to be done.

P.S. so what everyone is saying is: http://wiki.mikrotik.com/wiki/Two_gatew ... _balancing this is completely unusable since we have all kinds of problems that some solve with scripts and others try to solve with non working features... ?

OK, not all hope will be lost, if at least the WiKi example is fixed so that there is no more problems.

Thu Jan 22, 2009 4:59 pm

To : NetworkPro

I don't know why there are such examples (yes, all 3 examples), but they are complete b...s..t.

You need one code line for everything to work:

add dst-address=0.0.0.0/0 gateway=10.111.0.1,10.112.0.1 check-gateway=ping

It is ECMP route - it is per address-pair load balancing (not connection based load balancing). So if you connect from address1 to address2 and it goes via GW1 all other communications from address1 to address2 will use the same gateway.

nth can be used to acheive per packet load balancing, not per connection.

MikroTik, please, DELETE those wiki examples - they are uselessss

dsdee · Thu Jan 22, 2009 5:14 pm

macagiver,

your example won't work for the cases when there are two different ISPs with two different address spaces, and adaptations of the wiki samples will work.

With two different ISPs, you can't route packets with source addresses of one ISPs interface over the other ISPs network (and vice-versa), so you would need to be more specific in the routing for outbound packets. You would also need to account for packets that come in on one interface (ISP) and then be routed back out that same interface for the return packets; the example you provided doesn't provide for that case either.

While each of the various Mikrotik examples may not cover all specific cases, they do give users ideas of what might be adapted to their network to solve their individual problem(s).

NetworkPro · Thu Jan 22, 2009 5:43 pm

I have tried the ECMP scenario and it switched traffic each 3 minutes from one interface to the other, causing massive degradation of service. In my case the two Internet connections are a couple of PPPoE with the same Gateway address and different (dynamic) Public IPs assigned to each PPPoE dynamic interface. I used this:

add dst-address=0.0.0.0/0 gateway=ADSL1,ADSL2

and it failed miserably as described.

Right now, I need a working policy routing, possibly with failover. Without packet leakage out the wrong interface. How come stupid TP-LINK can make 4-port load balancing 400-600$ routers that are pretty much plug-n-play and the almighty Linux based MikroTik RouterOS can not accomplish this much needed function? This is a scandal.

NetworkPro · Fri Jan 23, 2009 3:07 am

To : NetworkPro

I don't know why there are such examples (yes, all 3 examples), but they are complete b...s..t.

You need one code line for everything to work:
Code: Select all
add dst-address=0.0.0.0/0 gateway=10.111.0.1,10.112.0.1 check-gateway=ping 
It is ECMP route - it is per address-pair load balancing (not connection based load balancing). So if you connect from address1 to address2 and it goes via GW1 all other communications from address1 to address2 will use the same gateway.

nth can be used to acheive per packet load balancing, not per connection.

MikroTik, please, DELETE those wiki examples - they are uselessss

Normy has just deleted the wiki examples. They will live on and we can honor their memory with this archived thread, remembering their lives dreams and hopes: http://forum.mikrotik.com/viewtopic.php?f=6&t=8870

P.S. they can be found here: http://www.rapidspread.com/file.jsp?id=kazcysy1pj preserved for our children.

Fri Jan 23, 2009 9:41 am

http://wiki.mikrotik.com/wiki/Load_Balancing_Persistent
This example should be used for the Load Balancing.

dsdee, I guess NAT will help you, when there are two different ISP.

NetworkPro, are you sure everything is fine with both gateways. We have tested the particular example and traffic is not switched every 3 minutes.

Let's take an example.
A is our client.
B is server 1.
C is server 2.

A is sending data to B, first gateway is selected. While there are any connections from A to B on the router, every packets should be sent over selected gateway.
As soon as all connection are closed between A and B, new packets from A to B can select another gateway (and B indeed is not B anymore, but C from the router point of view, as connection was closed previosly).

NetworkPro · Fri Jan 23, 2009 11:40 am

Sergej, thank you for taking care of your customers. I really will buy you a beer when I can.

My scenario is as follows:

Both ADSLs are PPPoE same ISP same Gateway IP, so can I safely use the new wiki example with PPPoE interface names instead of gateway IP address(es)? Last time I tried that, my connection to the router through the Internet, got dropped every few minutes. I guess I can try it again. This is taking me waaay to long and the customers behind that router better do not get near me because they will burn me and skin me and throw me to the pigs. Then CPR me back to life and skin me again.

I can give you login details, in case you want to try and implement it yourself.

Fri Jan 23, 2009 12:00 pm

To NetworkPro: your setup and my proposed setup are completely different setups, so how can you say that it is not working? ....

/interface pppoe-client print
/ip address
/ppp profile
/ip route
/ip firewall nat

and other menus that you think is important

Thanks, MT team for fixing wiki page

NetworkPro · Fri Jan 23, 2009 2:03 pm

With the following setup I connected with WinBox via each IP of the two ADSL IPs, first the ADSL2 got me disconnected then the ADSL1. Now I can not connect back. Until probably several minutes pass.

/interface pppoe-client> print

Flags: X - disabled, R - running 
 0  R name="ADSL1" max-mtu=1492 max-mru=1492 mrru=disabled interface=ether1 user="*" password="*" profile=default-compression-noMSS service-name="" ac-name="" add-default-route=no 
      dial-on-demand=no use-peer-dns=yes allow=pap,chap,mschap1,mschap2 

 1  R name="ADSL2" max-mtu=1492 max-mru=1492 mrru=disabled interface=ether2 user="*" password="*" profile=default-compression-noMSS service-name="" ac-name="" add-default-route=no 
      dial-on-demand=no use-peer-dns=yes allow=pap,chap,mschap1,mschap2

/ip address> print

Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   192.168.1.2/24     192.168.1.0     192.168.1.255   ether2
 1   192.168.6.2/24     192.168.6.0     192.168.6.255   ether1
 2   10.0.10.100/24     10.0.10.0       10.0.10.255     Bridge-WDS
 3 D 87.***.***.32/32   ***.***.*.234   0.0.0.0         ADSL1
 4 D 95.***.**.19/32    ***.***.*.234   0.0.0.0         ADSL2

ppp profile print

Flags: * - default

 0   name="default-compression-noMSS" use-compression=yes use-vj-compression=yes use-encryption=default only-one=default change-tcp-mss=no

(I set the MSS in mangle, so here it is mss=no)

ip route print

Flags: X - disabled, A - active, D -...
 #      DST-ADDRESS        PREF-SRC        GATEWAY-STATE GATEWAY  DISTANCE INTERFACE
 3 A S  ;;; ECMP Test
        0.0.0.0/0                          reachable     ADSL1    1        ADSL1
                                           reachable     ADSL2             ADSL2
 4 ADC  10.0.10.0/24       10.0.10.100                            0        Bridge-WDS
 5 ADC  192.168.1.0/24     192.168.1.2                            0        ether2
 6 ADC  192.168.6.0/24     192.168.6.2                            0        ether1
 7 ADC  ***.***.*.234/32   **.**.**1.19                           0        ADSL2
 8  DC  ***.***.*.234/32   ***.**.*22.32                          0        ADSL1

ip firewall nat print

Flags: X - disabled, I - invalid, D - dynamic

 0   chain=srcnat action=masquerade src-address=10.0.10.0/24

That's it.

NetworkPro · Fri Jan 23, 2009 2:20 pm

As you can see, in line 8 of route print, the gateway is considered not active (there is no A in front). So RouterOS, on some level, thinks that that gateway is unusable? Traffic is passing both the interfaces.

I am looking to solve all problems, including any possible packet leaks out the wrong ADSL interface.

Fri Jan 23, 2009 2:31 pm

I'm almost sure that your ISP server have MLPPP support.

If yes just create one PPPoE client with both interfaces (works only if username and password for both connections is same)

Why does your route rule Nr. 8 have no active flag????

NetworkPro · Fri Jan 23, 2009 2:36 pm

Probably because the gateway ip is the same. but I need this to work even without MLPPP and as far as I have tried the MLPPP did not fire up OK, active links was always 1. I will try again.

NetworkPro · Fri Jan 23, 2009 3:09 pm

Packets are still leaking, out both interfaces. I am starting do wonder if the packet sniffer uses connection tracking to replace IP addresses?

MLPPP is not working, active connections shows : 1

Back to square 1.

NetworkPro · Sat Jan 24, 2009 1:56 pm

help still needed

Mon Jan 26, 2009 10:46 am

Packets are still leaking, out both interfaces. I am starting do wonder if the packet sniffer uses connection tracking to replace IP addresses?

MLPPP is not working, active connections shows : 1

Back to square 1.

I gave it some thought: the only way how it should be possible on one box is MLPPP, you can forget about all other setups. if it is not working paste your configuration here and send a mail to support. Better explanation what went wrong would be nice. (some sniffer info, screenshots while BT)

Other solution would be connect links to different routers. - maybe even virtual routers!!!!

Create a 2 virtual routers and route them to host router - then a simple ECMP would solve the problem.
(have no idea about speed, but it would be very interesting to compare results.

NetworkPro · Tue Jan 27, 2009 2:35 am

I greatly appreciate your help, macgaiver, as well as others' help. Thank you.

Can you please tell me why the only solution would be MLPPP? Why can't it be done with better marking and routing? I think at least scripts can help solve it all. But it will be a cool challenge and a masterpiece of art.

You are suggesting that we try MLPPP again but what if the ISP does not support it? I know they use Juniper routers and that there are at least 4 AC MACs active at any given time with the same AC name. For MLPPP, don't we have to use the same AC (same MAC) for the two connections? Is MikroTik RouterOS capable of establishing correctly MLPPP in these circumstances? All my tests with MLPPP have led to active-connections:1.

For Virtual Routers, I guess I would need to upload Xen. Is it stable?

About the idea with the scripts: If the current problem is that packet leakage is caused by incorrect routing due to unknown Gateway IP(...setting the interface as Gateway instead of any IP/Dynamic Internet IP addresses on PPPoE interfaces...) - scripts could make adjust all rules to newly established dynamic PPPoE connections. A script could get the dynamic Internet IP and put it in any NAT and mangle rules, adjust routing rules accordingly etc. What do you think?

By the way, I have solved the problem that I was not able to connect reliably via the Internet. I used these:

/ip firewall mangle
add action=mark-connection chain=input connection-state=new in-interface=ADSL2 new-connection-mark=ADSL2Con2R passthrough=yes
add action=mark-connection chain=input connection-state=new in-interface=ADSL1 new-connection-mark=ADSL1Con2R passthrough=yes
add action=mark-routing chain=output connection-mark=ADSL2Con2R new-routing-mark=ToADSL2 passthrough=yes
add action=mark-routing chain=output connection-mark=ADSL1Con2R new-routing-mark=ToADSL1 passthrough=yes

/ip route rule
add action=lookup routing-mark=ToADSL2 table=ToADSL2
add action=lookup routing-mark=ToADSL1 table=ToADSL1

/ip route> print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - sthable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY-STATE GATEWAY    DISTANCE INTERFACE
 0 A S  ;;; Route All ToADSL2
        0.0.0.0/0                          reachable     ADSL2      1        ADSL2
 1 A S  ;;; ECMP Test
        0.0.0.0/0                          reachable     ADSL1      1        ADSL1
                                           reachable     ADSL2               ADSL2
 2 A S  ;;; Route All ToADSL1
        0.0.0.0/0                          reachable     ADSL1      1        ADSL1
 3 ADC  10.0.10.0/24       10.0.10.100                              0        Bridge-WDS
 4 ADC  192.168.1.0/24     192.168.1.2                              0        ether2
 5 ADC  192.168.6.0/24     192.168.6.2                              0        ether1
 6 ADC  212.**.**.234/32   **.**.***.33                             0        ADSL2
 7  DC  212.**.**.234/32   **.**.***.73                             0        ADSL1

The problem which I call "leaking packets" still remains. Internet users behind the router have not reported any big problems yet, as their websites seems to work. I myself am unable to travel to test Internet services like MSN etc behind that router, all I can do is over the Internet and I must not cut myself off with a misconfiguration.

P.S. I also have other routers and other people that need my support, waiting impatiently for a solution for this PPPoE scenario.

NetworkPro · Tue Jan 27, 2009 2:47 am

I'm almost sure that your ISP server have MLPPP support.

If yes just create one PPPoE client with both interfaces (works only if username and password for both connections is same)

The two ADSL accounts have different usernames and passwords. With this particular ISP, a PPPoE username and password can be used from anywhere, from any CPE MAC address.

So all MLPPP tests with one of the PPPoE accounts on both interfaces was unsuccessful. The ISP has a guest/guest (no Internet access) account that I tried as well. It had active connections:1 as well.

What do you suggest I try, that would not cut me off from the RB?

NetworkPro · Tue Jan 27, 2009 5:11 am

This is the NAT:

/ip firewall nat
add action=masquerade chain=srcnat comment=NAT src-address=10.0.10.0/24

And with this NAT log rules I can log everything else that would get NATed that is not the above:

add action=log chain=srcnat out-interface=ADSL1
add action=log chain=srcnat out-interface=ADSL2

And sure enough, I get this:

...
05:04:08 firewall,info srcnat: in:(none) out:ADSL1, proto UDP, 10.0.20.100:53->10.0.20.117:1034, len 60
05:04:25 firewall,info srcnat: in:(none) out:ADSL2, proto UDP, 10.0.20.100:53->10.0.20.111:3370, len 61
05:04:38 firewall,info srcnat: in:(none) out:ADSL2, proto UDP, 192.168.2.100:53->192.168.2.165:1026, len 61
05:04:53 firewall,info srcnat: in:(none) out:ADSL1, proto UDP, 10.0.20.100:53->10.0.20.117:1034, len 60
05:05:38 firewall,info srcnat: in:(none) out:ADSL1, proto UDP, 10.0.20.100:53->10.0.20.117:1034, len 60
05:05:43 firewall,info srcnat: in:(none) out:ADSL2, proto UDP, 192.168.2.100:53->192.168.2.165:1026, len 30

And 10.0.20.* and 192.168.2.* are in the internal network.

This is strange. Even if these packets get in through the local interface (Bridge-WDS) why are they forwarded and not dropped by default?

Tue Jan 27, 2009 10:11 am

The two ADSL accounts have different usernames and passwords...

That is the problem - MLPPP need same username sand passwords for both accounts.

The problem which I call "leaking packets" still remains. Internet users behind the router have not reported any big problems yet, as their websites seems to work. I myself am unable to travel to test Internet services like MSN etc behind that router, all I can do is over the Internet and I must not cut myself off with a misconfiguration.

05:04:08 firewall,info srcnat: in:(none) out:ADSL1, proto UDP, 10.0.20.100:53->10.0.20.117:1034, len 60
05:04:25 firewall,info srcnat: in:(none) out:ADSL2, proto UDP, 10.0.20.100:53->10.0.20.111:3370, len 61
05:04:38 firewall,info srcnat: in:(none) out:ADSL2, proto UDP, 192.168.2.100:53->192.168.2.165:1026, len 61
05:04:53 firewall,info srcnat: in:(none) out:ADSL1, proto UDP, 10.0.20.100:53->10.0.20.117:1034, len 60
05:05:38 firewall,info srcnat: in:(none) out:ADSL1, proto UDP, 10.0.20.100:53->10.0.20.117:1034, len 60
05:05:43 firewall,info srcnat: in:(none) out:ADSL2, proto UDP, 192.168.2.100:53->192.168.2.165:1026, len 30

But in here it is obvious that packets will not be captured by this nat rule:

/ip firewall nat
add action=masquerade chain=srcnat comment=NAT src-address=10.0.10.0/24

Just use out-interface option.
Or create a firewall filter to block this traffic.

NetworkPro · Tue Jan 27, 2009 11:43 am

The two ADSL accounts have different usernames and passwords...
That is the problem - MLPPP need same username sand passwords for both accounts.

True. And I knew it and tested accordingly.

The problem which I call "leaking packets" still remains. Internet users behind the router have not reported any big problems yet, as their websites seems to work. I myself am unable to travel to test Internet services like MSN etc behind that router, all I can do is over the Internet and I must not cut myself off with a misconfiguration.
Code: Select all
05:04:08 firewall,info srcnat: in:(none) out:ADSL1, proto UDP, 10.0.20.100:53->10.0.20.117:1034, len 60
05:04:25 firewall,info srcnat: in:(none) out:ADSL2, proto UDP, 10.0.20.100:53->10.0.20.111:3370, len 61
05:04:38 firewall,info srcnat: in:(none) out:ADSL2, proto UDP, 192.168.2.100:53->192.168.2.165:1026, len 61
05:04:53 firewall,info srcnat: in:(none) out:ADSL1, proto UDP, 10.0.20.100:53->10.0.20.117:1034, len 60
05:05:38 firewall,info srcnat: in:(none) out:ADSL1, proto UDP, 10.0.20.100:53->10.0.20.117:1034, len 60
05:05:43 firewall,info srcnat: in:(none) out:ADSL2, proto UDP, 192.168.2.100:53->192.168.2.165:1026, len 30 
But in here it is obvious that packets will not be captured by this nat rule:
Code: Select all
/ip firewall nat
add action=masquerade chain=srcnat comment=NAT src-address=10.0.10.0/24
Just use out-interface option.
Or create a firewall filter to block this traffic.

These are just logged in postrouting by [srcnat] facility. I have sniffed other packets with other addresses on the ADSL interfaces. This logging probably works because routing-decision sends them to postrouting, knowing there are log rules there.

omega-00 · Sat Jan 31, 2009 3:10 pm

I'm trying to achieve a similar thing with 2 seperate pppoe connections, my issue is not so much that user on the inside can't use the internet with my mangling rules in place, but that I'm unable to access the site remotely due to the way the routing allows traffic from ADSL1 to pass out over the ADSL2 interface (stopping any remote access)

I've also tried solving this with mangle rules trying to mark inbound connections to be passed out on the same interface with no luck.

As NetworkPro mentioned, I've also seen the 'leaking packets' issue. I even took a pcap of it occuring which I've linked.

http://www.epicwinrar.com/files/sniff.pcap

This was taken from the adsl2 interface (ip ending in 181) and as you can see it's trying to respond to packets original sent to adsl1 (ip ending in 145)
MLPPP is not available for this site via the ISP.

Firewall Connection Remove seems broken again v3.15, v3.16

Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15

Re: Firewall Connection Remove seems broken again v3.15

Re: Firewall Connection Remove seems broken again v3.15

3.17 too?

3.18?

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16

Re: Firewall Connection Remove seems broken again v3.15, v3.16