6 Feb
2016
6 Feb
'16
4:45 p.m.
Hi Swinogers
since a few weeks i see following messages
on a server in Europe
kernel:nf_ct_sip: dropping packetIN=eth0 OUT=
MAC=00:23:54:d7:7c:12:80:71:1f:e2:71:81:08:00 SRC=191.189.9.153
DST=62.75.177.146 LEN=513 TOS=0x00 PREC=0x00 TTL=115 ID=27879 PROTO=UDP
SPT=29012 DPT=5060 LEN=493
There are various IP´s causing this problem.
In common: all IP´s causing those Messages are originating from a CGN
Gateway
The example above is an Brazilian Cableprovider.
Client behind those networks complaining getting sometimes dropped
calls, or one way speech in some cases not able to Register some of
Sip-devices while others work. mostly in times the Kernel drop packets.
Does someone have any idea what is causing this ? even why the hell an
invalid MAC address could made it so far.
6 Feb
6 Feb
5:58 p.m.
On 2016-02-06 16:45, Roger wrote:
Hi Swinogers
since a few weeks i see following messages
on a server in Europe
kernel:nf_ct_sip: dropping packetIN=eth0 OUT=
MAC=00:23:54:d7:7c:12:80:71:1f:e2:71:81:08:00 SRC=191.189.9.153
DST=62.75.177.146 LEN=513 TOS=0x00 PREC=0x00 TTL=115 ID=27879 PROTO=UDP
SPT=29012 DPT=5060 LEN=493
There are various IP´s causing this problem.
In common: all IP´s causing those Messages are originating from a CGN
Gateway
The example above is an Brazilian Cableprovider.
Client behind those networks complaining getting sometimes dropped
calls, or one way speech in some cases not able to Register some of
Sip-devices while others work. mostly in times the Kernel drop packets.
SIP requires state, well, the RTP part of a SIP call requires state.
Some device is dropping state somewhere for you.
Welcome to the wonderful world of forced NAT.
Did you deploy IPv6 already? It is 2016, aka 201_IPv6_....
Does someone have any idea what is causing this ? even
why the hell an
invalid MAC address could made it so far.
Linux tends to show all the MAC addresses in a stack of packets, eg 802.1Q
00:23:54:d7:7c:12 is likely the switch you are connected to.
00:23:54 ASUSTek COMPUTER INC -- the VM bridge you are using?
80:71:1f:e2:71:81
80:71:1f Juniper Networks -- your actual router
08:00 just shows it is IPv4.
Greets,
Jeroen
7 p.m.
there is no ipv6 involved, not on dns nor on the server
its a physical machine with an MSI Board
i even see sometimes doubled packets.
I will have a talk with the Hoster as well ;)
but question is why it does only happen when there is CGN in the game ?
btw, here Embratel changed existing client to CGN and broke there
securitycams System (not reachable from the road)
There are several complain already pending at the Regulators office ;)
it was asked to investigate and even reduce the monthly fee for the time
of non 100% working Service.
It seems the regulator will soon add some rules regarding CGN.
Roger
On 06/02/2016 12:58, Jeroen Massar wrote:
On 2016-02-06 16:45, Roger wrote:
Hi Swinogers
since a few weeks i see following messages
on a server in Europe
kernel:nf_ct_sip: dropping packetIN=eth0 OUT=
MAC=00:23:54:d7:7c:12:80:71:1f:e2:71:81:08:00 SRC=191.189.9.153
DST=62.75.177.146 LEN=513 TOS=0x00 PREC=0x00 TTL=115 ID=27879 PROTO=UDP
SPT=29012 DPT=5060 LEN=493
There are various IP´s causing this problem.
In common: all IP´s causing those Messages are originating from a CGN
Gateway
The example above is an Brazilian Cableprovider.
Client behind those networks complaining getting sometimes dropped
calls, or one way speech in some cases not able to Register some of
Sip-devices while others work. mostly in times the Kernel drop packets.
SIP
requires state, well, the RTP part of a SIP call requires state.
Some device is dropping state somewhere for you.
Welcome to the wonderful world of forced NAT.
Did you deploy IPv6 already? It is 2016, aka 201_IPv6_....
Does someone have any idea what is causing this ?
even why the hell an
invalid MAC address could made it so far.
Linux tends to show all the MAC
addresses in a stack of packets, eg 802.1Q
00:23:54:d7:7c:12 is likely the switch you are connected to.
00:23:54 ASUSTek COMPUTER INC -- the VM bridge you are using?
80:71:1f:e2:71:81
80:71:1f Juniper Networks -- your actual router
08:00 just shows it is IPv4.
Greets,
Jeroen
_______________________________________________
swinog mailing list
swinog(a)lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
7:15 p.m.
On 2016-02-06 19:00, Roger wrote:
there is no ipv6 involved, not on dns nor on the
server
Of course not, otherwise there would not be any NAT issue.
its a physical machine with an MSI Board
i even see sometimes doubled packets.
Explain 'double packets', did you do a non-CGN test for that, do you see
them then.
I will have a talk with the Hoster as well ;)
but question is why it does only happen when there is CGN in the game ?
Likely as they balance their outbound load.
And then the source address changes maybe even in the middle of a session.
The only way to find out what happens is to be on both sides of that CGN
and monitor packets coming in/out of it. Or better: ask the people who
operate the CGN (and then also ask if they are deploying IPv6...)
btw, here Embratel changed existing client to CGN and
broke there
securitycams System (not reachable from the road)
Same is happening to UnityMedia all over Europe. And the people who are
signing up to new contracts with Cablecom do not even have the word "IP"
in their contacts, these will soon have a nice 500/10mbit CGN'd pipe too.
There are several complain already pending at the
Regulators office ;)
it was asked to investigate and even reduce the monthly fee for the time
of non 100% working Service.
It seems the regulator will soon add some rules regarding CGN.
That is a good precedent. Unfortunately as I note above, they already
have changed the contracts, hence folks "changing" their subscription
agree with the new one which does not even do "IP", just "Internet"
which is rather vague.
Greets,
Jeroen
Roger
On 06/02/2016 12:58, Jeroen Massar wrote:
On 2016-02-06 16:45, Roger wrote:
_______________________________________________
swinog mailing list
swinog(a)lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Hi Swinogers
since a few weeks i see following messages
on a server in Europe
kernel:nf_ct_sip: dropping packetIN=eth0 OUT=
MAC=00:23:54:d7:7c:12:80:71:1f:e2:71:81:08:00 SRC=191.189.9.153
DST=62.75.177.146 LEN=513 TOS=0x00 PREC=0x00 TTL=115 ID=27879 PROTO=UDP
SPT=29012 DPT=5060 LEN=493
There are various IP´s causing this problem.
In common: all IP´s causing those Messages are originating from a CGN
Gateway
The example above is an Brazilian Cableprovider.
Client behind those networks complaining getting sometimes dropped
calls, or one way speech in some cases not able to Register some of
Sip-devices while others work. mostly in times the Kernel drop packets.
SIP
requires state, well, the RTP part of a SIP call requires state.
Some device is dropping state somewhere for you.
Welcome to the wonderful world of forced NAT.
Did you deploy IPv6 already? It is 2016, aka 201_IPv6_....
Does someone have any idea what is causing this ?
even why the hell an
invalid MAC address could made it so far.
Linux tends to show all the MAC
addresses in a stack of packets, eg
802.1Q
00:23:54:d7:7c:12 is likely the switch you are connected to.
00:23:54 ASUSTek COMPUTER INC -- the VM bridge you are using?
80:71:1f:e2:71:81
80:71:1f Juniper Networks -- your actual router
08:00 just shows it is IPv4.
Greets,
Jeroen
_______________________________________________
swinog mailing list
swinog(a)lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
2787
days inactive
2787
days old
3 comments
2 participants
participants (2)
-
Jeroen Massar -
Roger