华为USG与思科ASA串联防火墙会话老化时间不一致导致业务中断的排查与配置

1. 问题背景：一个典型的“串联防火墙”业务中断现场

先说一个我实际遇到的案例。某企业客户内网有两段业务，中间串联了两台防火墙——靠近互联网出口是一台华为USG，核心业务区前面是一台思科ASA。拓扑很简单：服务器 → 思科ASA → 华为USG → 交换机 → 办公终端。平时跑着ERP、文件共享和一些老旧的C/S架构应用。业务量不大，但很关键，断个几分钟业务部门就会打电话过来。

某天开始，用户陆续反馈“用着用着就卡一下，过一会儿又自己好了”，更严重的时候ERP会直接掉线，重新登录才能继续。看了一圈网络设备，物理链路、CPU、内存都没问题，路由器也没有丢包。排查方向一度转向了服务器和交换机，结果都没有异常。最后把抓包位置放在两台防火墙之间，才发现了端倪。

问题出在华为USG和思科ASA的会话老化时间（session aging time）不一致上。这两台设备串联在同一条业务链路上，对于同一条TCP连接，各自维护着自己的会话表，但双方对“这条连接多久没数据就算过期”的判断标准完全不同。上游已经判定连接老化并删掉了会话，下游却还在傻等；等业务流量再次出现时，设备之间的状态就对不上了，于是表现为间歇性卡顿、掉线。

这个案例很有代表性，因为很多中型企业都会在出口和核心区各放一台防火墙，而且是不同品牌的。防火墙串联本身不是问题，问题在于会话状态的协同。如果你也遇到过“双防火墙串着用，业务总是不稳定”的毛病，这一篇值得仔细看一遍。

2. 会话老化时间机制：两张会话表为什么必须对得上

2.1 防火墙为什么要管“会话老化”

要搞懂这个故障，先要明白防火墙不是简单的包过滤器。它工作在状态检测模式（stateful inspection）下，会为每一条经过的TCP/UDP连接建立一张会话表，记录五元组信息（源IP、目的IP、源端口、目的端口、协议）、连接状态、超时时间，以及NAT转换前后的映射关系。

防火墙为什么要给连接“计时”？因为连接不可能永远存在。当一条连接在指定时间内没有任何数据包经过，防火墙就认为它已经结束了，把会话从内存里删掉，释放资源。这个“指定时间”就是session aging time，中文叫会话老化时间或会话超时时间。

你可以把它理解成一个停车场的自动闸机。车进场时抬杆放行，同时开始倒计时；如果车辆在规定时间内没有再次出场动作，就默认车已经离开了，闸机恢复到关闭状态。问题是，前后两个停车场如果倒计时规则不一样，就会出现前面闸机已经关了、后面闸机还开着，或者反过来，导致车辆无法顺利通行。

2.2 华为USG和思科ASA的默认老化时间差异

华为USG（基于VRP平台）的会话老化时间按协议区分管理，默认值大概是这样的：

思科ASA的默认配置走的是“全局连接超时+协议独立超时”的路线：

注意看，华为USG的TCP默认是1800秒，思科ASA的timeout conn默认是3600秒，timeout tcp是1800秒。表面上TCP层的超时时间差不多，但实际生效的“包在外面”的那个参数是timeout conn，它决定了一条连接最长可以空闲多久才被标记为超时。

我遇到的这个案例里，华为USG保持默认的1800秒TCP老化，思科ASA则被人为调成了timeout conn 0:30:00（30分钟），同时timeout tcp 0:10:00（10分钟）。看配置的人本意是想让TCP空闲超时短一点，尽早回收连接，避免会话表被占满。

但问题恰恰出在这里：华为USG认为一条TCP连接1800秒没流量就该清掉，而思科ASA认为1200秒就该清掉。两台设备对同一业务流的生命周期判断差了600秒，中间就出现了一个“时间窗口”——在这个窗口内，思科ASA的会话已经被清掉，华为USG的会话还活着。业务流量再次到达时，华为USG还认这条连接，直接把包放行，但思科ASA的会话表里已经没有对应条目，按安全策略判断这是一个“新连接”，如果思科的默认策略拒绝新连接，业务就直接被中断了。

2.3 为什么串联场景下老化时间不一致会出问题

单台防火墙的环境里，老化时间配置不当最多影响资源回收效率，不会造成业务中断，因为设备对自己维护的连接状态有完全的控制权。但两台不同品牌、不同老化机制的防火墙串在一条链路上时，事情就变了。

数据包经过两台设备时，本质上经过了两次独立的会话状态检查。第一台设备查自己的会话表，如果命中就放行，没命中就按新连接处理；第二台设备再做一遍同样的判断。两台设备之间没有任何会话同步机制——华为USG不知道思科ASA删了什么会话，思科ASA也不知道华为USG还留着什么会话。

于是只要两台设备对同一条连接的空闲判定不一致，就会出现会话表“错位”。表现到业务上就是：

• 业务流量间歇性中断。长连接应用（比如ERP客户端、SSH、数据库连接池、文件共享）表现最明显。
• 连接重建频繁。客户端收到RST包或直接超时，被迫重新建立连接。
• 偶发丢包。流量到达时两台设备状态不一致，有的放行有的拦截，结果对端收不到完整数据流。
• 排查困难。因为不是持续断网，是“一阵一阵的”，很多时候抓包也抓不到明显错包，非常容易把方向引到应用层或服务器上。

这个问题的本质不是某一台设备的配置错误，而是两台设备之间的会话生命周期策略不协同。理解了这一点，后面的配置思路就清晰了——必须把串联链路上所有设备的会话老化时间对齐，而不是各管各的。

3. 华为USG和思科ASA的配置实操：对齐老化时间

3.1 先查当前老化时间配置

动手改配置之前，先把两台设备的现状摸清楚。这条原则在任何网络变更里都适用，你先要知道现在是什么状态，才能判断改完是否生效。

华为USG上查看会话老化时间：

bash复制system-view
display firewall session aging-time

输出会按协议列出当前的超时时间，比如：

code复制tcp                   1800    seconds
udp                   120     seconds
icmp                  20      seconds

如果你只想看某一种协议，可以加参数过滤：

bash复制display firewall session aging-time tcp

思科ASA上查看连接超时配置：

bash复制show running-config timeout

输出类似：

code复制timeout conn 1:00:00
timeout tcp 0:30:00
timeout udp 0:02:00
timeout icmp 0:02:00

也可以用show conn看当前实际的连接会话表，但这个命令显示的是动态会话，不是超时配置。如果有需要，show conn detail能看每条连接剩余的空闲时间。我在排查时经常用这个命令来判断某条业务连接在两台设备上的生命周期状态，非常直观。

3.2 华为USG配置会话老化时间

华为USG会话老化时间在系统视图下配置，命令格式如下：

bash复制system-view
firewall session aging-time tcp 1800
firewall session aging-time udp 120
firewall session aging-time icmp 20

tcp后面的参数单位是秒，取值范围和协议相关，不同型号略有差异。配置完不会立即影响已有会话，新配置只对后续新建的连接生效——这一点容易踩坑，后面会细说。

如果你想配置的是“某种特定应用的长连接”，比如数据库同步或消息推送场景，可以通过应用识别来单独设置超时，避免全局调大导致会话表膨胀。不过在这个案例里，核心动作就是把TCP老化时间跟对端设备对齐，全局调整就够了。

配置完后确认：

bash复制display firewall session aging-time

能看到配置已经生效。

3.3 思科ASA配置连接超时

思科ASA的超时配置在全局配置模式下执行：

bash复制configure terminal
timeout conn 0:30:00
timeout tcp 0:30:00

timeout conn的格式是小时:分钟:秒，一般写成0:30:00代表30分钟。timeout tcp单独控制TCP协议的空闲超时，timeout udp控制UDP，timeout icmp控制ICMP。

这里有个容易被忽略的知识点：timeout conn是所有连接的总控超时，timeout tcp是TCP协议的独立超时，最终一条TCP连接的老化时间取两者中较短的那个。所以如果timeout conn设了60分钟，timeout tcp设了10分钟，那TCP连接实际10分钟就会老化。

配置完同样确认：

bash复制show running-config timeout

3.4 两边的配置值怎么定才合理

对齐老化时间不是简单地把两边设成同一个数字就完事了，还要结合业务场景判断这个数字是否合理。我后来是把华为USG和思科ASA都统一成了1800秒（30分钟），原因有三点：

第一，TCP连接30分钟空闲超时对绝大多数办公室业务都够用。ERP客户端如果30分钟没有任何SQL查询，那这条连接基本可以判定为闲置，重新连接的成本远低于长期占着会话表资源。

第二，华为USG默认TCP老化就是1800秒，改成这个值属于“回归默认”，修改的配置面最小，后续维护的人一看就懂。

第三，思科ASA从3600秒降到1800秒，会话表占用会降低一半左右。对于峰值连接数较高的设备，这是一个正向优化。

如果业务里有需要长时间保持连接的应用，比如数据库主从同步、WebSocket长连接、SSH隧道，那就不能一刀切设成30分钟。要么单独给这些应用配置超时，要么统一拉长到3600秒。但拉长有一个代价：会话表里闲置连接占用的内存和表项更多，设备并发能力会下降。所以我的建议是——先明确业务需求，再定老化时间；两边对齐了之后，再考虑是全局统一还是按应用区分。

3.5 修改老化时间后要不要重启设备

不需要。华为USG和思科ASA的会话老化时间都是动态生效的，不需要重启，也不会中断现有连接。改完配置后，新建立的连接会按照新老化时间开始计时；已经存在的连接会继续按旧配置跑，直到它们自然结束或被清除。

这个特性有两个实际意义：

• 你可以在业务低峰期安全地修改配置，不需要申请变更窗口来重启设备。
• 但如果一线业务已经有异常连接卡在“错位”状态，改完配置后这些旧连接并不会自动恢复，需要手动清掉相关会话，让业务重新建立连接。清除会话的命令如下：

华为USG：

bash复制reset firewall session table

这个命令会清空整张会话表，影响范围大，只能在业务低峰期执行。更精细的操作是只清除某个源IP的会话：

bash复制reset firewall session table ipv4 source-ip 192.168.1.10

思科ASA清除连接：

bash复制clear conn address 192.168.1.10

如果是只清某一条连接，可以先show conn查到连接ID，然后clear conn conn-id精确清除。

4. 真实故障排查与避坑技巧实录

4.1 我踩过的坑：只对齐TCP老化时间，UDP还是对不上

第一次处理类似问题时，我把华为USG和思科ASA的TCP老化时间都设成了1800秒，以为万事大吉。结果第二天VoIP电话系统还是出现通话中断的情况。

查了一圈才发现，问题出在UDP上。华为USG的UDP默认老化是120秒，思科ASA的timeout udp默认也是120秒，表面看是一致的。但VoIP的RTP流走的不是标准UDP应用端口，两台防火墙对这条UDP流的判定逻辑不同——华为USG根据流量特征识别为VoIP媒体流，自动套用了更长的老化时间；思科ASA这边没有开启VoIP协议的深层检测，走的还是普通UDP的120秒超时。

所以两台设备的实际会话生命周期还是错位的，根本原因在于应用协议识别能力不同，而不只是老化时间参数。

这个案例给了一个非常重要的教训：彻底对齐不能只看同名配置项，还要考虑应用识别带来的隐形差异。如果你的业务里有VoIP、视频会议、数据库同步这类对连接时长敏感的应用，最好在两台设备上都把对应协议的超时策略单独确认一遍，而不是只靠全局参数兜底。

4.2 排查步骤：从现象到根因的思路

遇到“串联防火墙导致业务时断时续”的场景，我建议按下面的顺序排查，能少走很多弯路：

第一步，确认拓扑。画清楚业务流量经过了哪些防火墙，明确流量路径。可以看路由表，也可以在防火墙上开抓包确认。

第二步，看两台设备上的会话是否存在。在业务出现卡顿的时间点，分别在华为USG上执行display firewall session table，在思科ASA上执行show conn，过滤业务源IP，对比同一时间戳下两边会话表里有没有对应条目。

第三步，对比会话残留时间。如果华为USG上会话还在，思科ASA上已经消失了，基本可以判定老化时间不一致。

第四步，检查两端安全策略。有时候不是会话老化时间的问题，而是策略拒绝新连接导致的。把老化问题排除后，再确认策略放行逻辑是否一致。

第五步，在会话层面做一次“最终对齐测试”。把两边会话同时清掉，重新发起业务流量，观察是否恢复正常。如果不恢复，说明还有其他因素，比如NAT配置、路由不对称、MTU问题。

我用这个流程处理过三次类似故障，每一次都能精准定位到会话老化时间错位。原因很简单——这个问题有一个典型特征：业务空闲一段时间后再操作就卡顿，越是不常用的模块越容易触发。只要抓住这个特征，排查方向就不会跑偏。

4.3 常见问题速查表

4.4 几个我长期使用的运维习惯

说完问题，再说几个我在日常运维中总结出来的习惯，不一定写在哪本手册里，但对减少这类故障很有帮助。

第一，串联防火墙建议统一品牌或多花点成本做会话同步。如果条件允许，两台同品牌防火墙可以做集群或HA，会话表实时同步，从根本上避免老化时间不一致的问题。但如果预算和现状决定了必须用两个品牌串联，那就把老化时间对齐这件事写进变更清单，每次有设备配置变更都复查一遍。

第二，修改老化时间后一定要做业务验证，不能只看配置下发成功就完事。我习惯在业务低峰期改完配置后，手动清掉业务相关会话，再让业务端重新连一次，验证连接能正常建立、空闲一段时间后再操作依然顺畅。全程记录验证结果，形成文档备查。

第三，给会话老化时间相关的配置加备注。华为USG和思科ASA都支持在配置里写description或remark，把“为什么设这个值、跟哪台设备对齐、对应什么业务”写清楚。半年后接手的同事看到配置不会一头雾水，也不会在不知情的情况下改掉关键参数。

第四，监控会话表容量峰值。定期导出两台设备的高峰会话数和会话表上限，如果发现某台设备的会话数长期超过其上限的70%，就得考虑调短老化时间或扩充设备能力。会话表溢出也会导致连接异常，而且这种异常往往被误判为老化时间问题。

4.5 华为USG和思科ASA在会话机制上的一个差异点

再补充一个容易被忽略的差异。华为USG对TCP连接的会话老化是从“最后一个报文”开始计时的，只要有数据包经过，老化计时器就会自动重置。思科ASA的timeout conn行为类似，但它的timeout tcp在某些场景下会针对半开连接（SYN没完成握手的状态）单独计时，半开连接的超时时间往往比普通连接短很多。

这个差异意味着：如果业务里有一些TCP连接建立后长时间不发送数据（比如SSH闲置会话、数据库连接池的空闲连接），华为USG会认为连接仍然活跃，而思科ASA可能已经因为半开连接超时把状态清掉了。表现形式同样是“用着用着突然掉线”。

解决办法有两种：一是开启TCP keepalive，让应用层定期发送心跳包，保持连接活跃；二是把半开连接超时调大。思科ASA上执行：

bash复制show run timeout

看有没有针对半开连接的配置，比如timeout tcp-proxy-reassembly，或者用timeout conn带着更长的全局值覆盖。

华为USG侧则可以通过开启TCP增强老化选项，让设备对正常TCP连接的判定更宽松。具体命令因版本而异，建议查阅对应版本配置指南，核心思路就是让两台设备对“半开连接、闲置连接”的判定逻辑尽量一致。

5. 最后分享一点实战心得

处理完这个故障后，我做了一个小复盘，发现一个挺有意思的事：这套环境里华为USG和思科ASA都承担着重要的安全职责，平时的策略配置、日志审计、入侵防御都做得很细致，但偏偏在最基础的“连接生命周期管理”上栽了跟头。

原因不难理解。安全团队关注的是策略和威胁，网络团队关注的是路由和转发，会话老化时间处在两者的交界地带——它不影响安全策略的正确性，也不影响路由的有效性，但实实在在影响着业务连接的稳定性。没有遇到过这类故障的人，很难意识到这个参数需要跨品牌协同。

不少运维同行看到“session aging time”这个词，第一反应是“就一个超时参数，随便设设就行”。但串联场景下，它就是那个最容易阴沟里翻船的地方。两台设备各自为政，任何一边调整了老化时间，另外一边没有同步调整，故障只是早晚的问题。

我的习惯做法是：每半年做一次设备配置健康检查，把串联链路上所有防火墙的会话老化时间放在一张表里对比，协议逐个核对。这个动作成本很低，也就十分钟，但能提前发现很多潜在问题。

如果你接下来要处理类似的串联防火墙环境，建议先把这两条命令存在手边——华为USG的display firewall session aging-time和思科ASA的show running-config timeout。任何时候怀疑业务间歇性中断和防火墙有关，第一件事就是跑这两条命令，把两张表摆在一起看。很多时候，答案就在对比之间。