Hi Guy's,
Anyone care to test if this fixes the issue?
I dont have a pppoe myself , but do think everyone with a changing wan
ip is affected by old udp states that stay alive long after a outbound
natted ip has changed..
I think there is no danger in dropping all states that use that specific
old ip, as it nolonger is used by pfSense and you wouldnt know where
might exist now..
Place the code below in the file /etc/rc.newwanip at the bottom of the
file just before the ?>
--------------------------
if (is_ipaddr($oldip) && $curwanip != $oldip) {
/* Reset states that are using the wan-ip, for example outbound natted
udp traffic would otherwise stay natted using the old wan-ip */
mwexec_bg("/sbin/pfctl -k $oldip");
}
--------------------------
Please report back if this fixes the issue, or if any unwanted
side-effects occur..
Ive send a pull-request for pfSense 2.2 containing this change:
https://github.com/pfsense/pfsense/pull/1299/files
p.s. im not a 'pfSense dev' , just a user and contributer.. use it at
your own risk ;)..
Greets PiBa-NL
Espen Johansen schreef op 28-9-2014 19:26:
If this is to be implemented it should be a tick box on each
interfance. Dropping all states if you want to move a cable/reroute it
is not a good idea.
This needs to be user controllable or only affect interface if
is_interface_type=pppoe.
Just my 2 cents.
-lsf
28. sep. 2014 19:19 skrev "Hannes Werner" <[email protected]
<mailto:[email protected]>> følgende:
I would like to repeat Vassilis questions:
Has this been implemented? Could this be implemented? Do the pfsense
dev's need some more info? Can we help with testing?
On Sat, Sep 27, 2014 at 1:02 PM, Vassilis V. <[email protected]
<mailto:[email protected]>> wrote:
> ADSL over PPPoE with constant changing IPs is the standard in some
> countries, we do not have such connections because we chose them
and we
> like the challenge..
>
> Reading again the whole bug report, there seems to be alot of people
> affected by this and Tom De Coninck has made alot of effort to
figure
> out what might be the issue.
>
> In the last post of Tom, he comes to a very exact conclusion:
> "I think this proves that pfsense not only needs to kill states
on 'WAN
> DOWN' , but also on 'WAN UP'. I can't see how it could work
otherwise"
>
> Has this been implemented? Could this be implemented? Do the pfsense
> dev's need some more info? Can we help with testing?
>
> Vassilis
>
>
> Hannes Werner wrote on 26.09.2014 22 <tel:26.09.2014%2022>:53:
>> Thanks Vassilis,
>>
>> I've these settings already - without any success.
>>
>> On Fri, Sep 26, 2014 at 9:03 PM, Vassilis V.
<[email protected] <mailto:[email protected]>> wrote:
>>>
>>>
>>> Hannes Werner wrote on 26.09.2014 16 <tel:26.09.2014%2016>:51:
>>>> thank you very much Giles, but unfortunately it doesn't help.
>>>>
>>>> anyone here who is using asterisk behind pfSense on a dynamic
IP WAN
>>>> successfully?
>>>>
>>>
>>> Hello Hannes!
>>>
>>> I have also used asterisk behind a dynamic PPPoE WAN. I had
the exact
>>> same issues that the bug report is describing.
>>>
>>> I tried different ways to get it to work and I found that some
solutions
>>> work with some providers, but fail at others. There seems to
be alot of
>>> black magic involved when configuring SIP to work in such a
configuration :)
>>>
>>> What worked best was to set nat=no and externip=<the local
asterisk IP>.
>>> I had also not done any port forwards whatsoever on pfsense,
outgoing
>>> NAT was set to automatic.
>>>
>>> I certainly cannot explain why it was working that way!
>>>
>>>
>>> Hope it helps!
>>> Vassilis
>>> _______________________________________________
>>> List mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.pfsense.org/mailman/listinfo/list
>> _______________________________________________
>> List mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.pfsense.org/mailman/listinfo/list
>>
> _______________________________________________
> List mailing list
> [email protected] <mailto:[email protected]>
> https://lists.pfsense.org/mailman/listinfo/list
_______________________________________________
List mailing list
[email protected] <mailto:[email protected]>
https://lists.pfsense.org/mailman/listinfo/list
_______________________________________________
List mailing list
[email protected]
https://lists.pfsense.org/mailman/listinfo/list
_______________________________________________
List mailing list
[email protected]
https://lists.pfsense.org/mailman/listinfo/list
