Она не идет после 100 маршрутов!!! Она вообще не идет, просто выдается конечный адрес. Если ввести например адрес провайдера то он выдаст ответ через 3 маршрута. Первый 2 из которых будут с превышенным интервалом времени.



Чтоже тогда делать?

Вот моя трассировка через устройство и правила:
traceroute -n 219.114.51.20
traceroute 30 hops max, 40 byte packets
1 * * * <-- DFL
2 192.168.100.1 1.057 ms 0.607 ms 0.603 ms
3 212.46.14.129 0.827 ms 0.814 ms 0.802 ms
4 212.46.9.129 3.729 ms 3.214 ms 3.616 ms
5 212.46.9.146 3.556 ms 3.654 ms 9.410 ms
6 193.232.212.1 9.442 ms 4.544 ms 4.338 ms
7 193.232.244.228 8.181 ms 9.038 ms 8.890 ms
8 * * * <-- Запрет
9 219.114.51.20 10.095 ms 8.420 ms 17.411 ms

скрин настройки правила в аттаче, прошивка 1.35

по поводу второго
нужно разбиратся какая из систем не выполняет требования, настроить устройство чтобы оно этого не замечало не получится.

Ну и что же там странного?
ИМХО, ОЧЕВИДНО и элементарно!!! Что до хоста не вернулся ни один ICMP-пакет "Time exceeded" (type 11). С вероятностью 90% их порезал этот самый роутер.
А последний ответ вернулся как ICMP "Echo replay" (type 0) и роутер его пропустил.

Ну а на приведённой (viewtopic.php?p=184850#184850) картинке смущает название "Service" - "Traceroute-udp", особенно в связи с тем, что не все ОС трассируют с использованием udp. В Win tracert использует ICMP, а есть и tracetcp

Похоже, это 2 вечные темы форума - настройка FTP за роутером и трассировки через DFL

Видимо обязательно требуется правило ping-outbound, без него он дропает ответы.

В картинке Козлова это правило есть - №3
Но трассировку то он делает ид под *nix, а там она, AFAIK, или udp-шная или может быть таковая.

Какие именно? При ICMP-трассировке ответы как минимум двух типов - type 11 и 0.

Описание службы:
ping-outbound ICMP: Echo (Ping) Return ICMP Errors

У автора темы этого правила как раз нет, отсюда видимо и проблема. В DFLке как обычно all_service это не любой траффик.

Давайте для начала подождём ответа автора топика.

проблемма с трассировкой решилась именна так.

Второй вопрос все еще висит.

Что это за программа напишите.

eQSO программа для связи радиолюбителей.

Да и Радмин тоже не хочет коннектиться выдает тотже LogStateViolations, хотя пинг есть.
На этот раз комп клиент в LAN а сервер в DMZ


2007-03-15 16:34:57 Local3.Notice [адрес DFL700] EFW: DROP: rule=LogStateViolations event=unexpected_tcp_flags flags="SYN" endpoint=originator state=FIN_RCVD connipproto=TCP connrecvif=LAN connsrcip=[адрес клиента] connsrcport=1029 conndestif=DMZ conndestip=[адрес сервера] conndestport=4899 origsent=352 termsent=0 recvif=LAN srcip=[адрес клиента] destip=[адрес сервера] ipproto=TCP ipdatalen=28 srcport=1029 destport=4899 tcphdrlen=28 syn=1

Возник еще один вопрос под DFL700
На LAN стоит адрес 172,21,5,*
на DMZ стоит адрес 192,168,7,*
В правилах DMZ->LAN и LAN->DMZ стоит Any Protocols для любых адресов. НАТ выключен в обоихслучаях. Цель маршрутизация чтобы компы из обоих подсетей видели друг друга. На компах указаны шлюзы - адреса LAN и DMZ портов соответсвенно.
В принципе цель достигнута, но почемуто стали забиваться логи такими записями.

[2007-03-15 19:04:12] <5>EFW: DROP: rule=Default_Access_Rule action=drop recvif=DMZ srcip=172.21.5.99 destip=172.21.5.255 ipproto=UDP ipdatalen=58 srcport=137 destport=137 udptotlen=58

[2007-03-15 19:03:37] <5>EFW: DROP: rule=Default_Access_Rule action=drop recvif=LAN srcip=192.168.7.89 destip=192.168.7.255 ipproto=UDP ipdatalen=225 srcport=138 destport=138 udptotlen=225

Вопрос в чем дело? Интересно то что в дропе для DMZ стоит адрес из LAN и наоборот. Такие ошибке идут постоянно причем srcip разный а destip всегда такой же как srcip но с последним адресом 255

Это Netbios рассылки, а роутер их просто дропает, так как не настроен на пересылку.

если несложно подскажите как это личить, а то логи растут катастрофически